A Layer 2 VPN Network YANG Model
draft-ietf-opsawg-l2nm-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9291.
|
|
|---|---|---|---|
| Authors | Samier Barguil , Oscar Gonzalez de Dios , Mohamed Boucadair , Luis Angel Munoz | ||
| Last updated | 2021-04-30 | ||
| Replaces | draft-barguil-opsawg-l2sm-l2nm | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-15)
by Dale Worley
Ready w/nits
YANGDOCTORS Last Call review
(of
-07)
by Ladislav Lhotka
Ready w/issues
RTGDIR Early review
(of
-01)
by Yingzhen Qu
Has issues
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 9291 (Proposed Standard) | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-opsawg-l2nm-02
OPSAWG S. Barguil, Ed.
Internet-Draft O. Gonzalez de Dios, Ed.
Intended status: Standards Track Telefonica
Expires: November 1, 2021 M. Boucadair , Ed.
Orange
L. Munoz
Vodafone
April 30, 2021
A Layer 2 VPN Network YANG Model
draft-ietf-opsawg-l2nm-02
Abstract
This document defines a YANG data model (called, L2NM) that can be
used to manage the provisioning of Layer 2 VPN services within a
service provider Network. The L2NM provides representation of the
Layer 2 VPN services from a network standpoint. The L2NM is meant to
be used by a network controller to derive the configuration
information that will be sent to relevant network devices.
The L2NM complements the Layer 2 Service Model by providing a
network-centric view of the service that is internal to a service
providers.
Editorial Note (To be removed by RFC Editor)
Please update these statements within the document with the RFC
number to be assigned to this document:
o "This version of this YANG module is part of RFC XXXX;"
o "RFC XXXX: Layer 2 VPN Network Model";
o reference: RFC XXXX
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 module.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Barguil, et al. Expires November 1, 2021 [Page 1]
Internet-Draft L2NM April 2021
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 November 1, 2021.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Reference Architecture . . . . . . . . . . . . . . . . . . . 5
5. Relation with other YANG Models . . . . . . . . . . . . . . . 8
6. Description of the L2NM YANG Module . . . . . . . . . . . . . 10
6.1. Structure of the Module . . . . . . . . . . . . . . . . . 10
6.2. VPN Profiles . . . . . . . . . . . . . . . . . . . . . . 10
6.3. L2VPN Service . . . . . . . . . . . . . . . . . . . . . . 12
6.3.1. Global Parameters Profiles . . . . . . . . . . . . . 15
6.3.2. VPN Node . . . . . . . . . . . . . . . . . . . . . . 16
6.3.2.1. Signaling Options . . . . . . . . . . . . . . . . 18
6.3.2.2. VPN Network Access . . . . . . . . . . . . . . . 21
6.3.2.2.1. Connection . . . . . . . . . . . . . . . . . 23
6.3.2.2.2. Services . . . . . . . . . . . . . . . . . . 25
7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 69
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 71
Barguil, et al. Expires November 1, 2021 [Page 2]
Internet-Draft L2NM April 2021
10.1. Normative References . . . . . . . . . . . . . . . . . . 71
10.2. Informative References . . . . . . . . . . . . . . . . . 73
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 74
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 74
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 75
1. Introduction
[RFC8466] defines an L2VPN Service Model (L2SM) YANG data model that
can be used for L2VPN service ordering matters between customers and
service providers (SPs). This document complements the L2SM by
creating a network-centric view of the service which can be exposed
by a network to a service controller within the service providers
network. In particular, the model can be used in the communication
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).
The data model defined in this document is called the L2VPN Network
Model (L2NM), playing the role of Service Delivery Model (Figure 3 of
[RFC8466]). The module supports additional capabilities, such as
exposing operational parameters, transport protocols selection and
precedence. It also serves as a multi-domain orchestration
interface, because this model can transport resources (i.e., VCID)
between domains. The data model keeps minimum customer-related
information.
This document uses the common VPN YANG module defined in
[I-D.ietf-opsawg-vpn-common].
The YANG data model in this document conforms to the Network
Management Datastore Architecture (NMDA) defined in [RFC8342].
2. Terminology
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.
Barguil, et al. Expires November 1, 2021 [Page 3]
Internet-Draft L2NM April 2021
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 uses the term "network model" defined in Section 2.1 of
[RFC8969].
This document makes use of the following terms:
L2 VPN Customer Service Model (L2SM): Describes the service
characterization of an L2VPN that interconnects a set of sites
from the perspective of the customer. The customer service model
does not provide details on the service provider network. The
L2VPN customer service model is defined in [RFC8466].
L2 VPN Service Network Model (L2NM): Refers to the YANG module that
describes an L2VPN service with a network-centric view. It
contains information of the service providers network and might
include allocated resources. It can be used by network
controllers to manage the Layer 2 VPN service configuration in the
service providers network. The YANG module can be consumed by a
service orchestrator to request a VPN service to a network
controller or to expose the list of active L2VPN services.
Service orchestrator: Refers to a functional entity that interacts
with the customer of an L2VPN relying upon, e.g., L2SM. The
service orchestrator is responsible of the CE-PE attachment
circuits, the PE selection, and requesting the activation of the
L2VPN service to a network controller.
Network controller: Denotes a functional entity responsible for the
management of the service providers network.
VPN node: Is an abstraction that represents a set of policies
applied on a PE and that belong to a single VPN service. A VPN
service involves one or more VPN nodes. The VPN node will
identify the service providers node on which the VPN is deployed.
VPN network access: Is an abstraction that represents the network
interfaces that are associated to a given VPN node. Traffic
coming from the VPN network access belongs to the VPN. The
attachment circuits (bearers) between CEs and PEs are terminated
in the VPN network access.
VPN Service Provider (SP): Is a service providers that offers L2VPN-
related services.
Barguil, et al. Expires November 1, 2021 [Page 4]
Internet-Draft L2NM April 2021
Service Provider Network (SP Network): Is a network able to provide
L2VPN-related services.
3. Acronyms
The following acronyms are used in the document:
ACL Access Control List
BGP Border Gateway Protocol
CE Customer Edge
L2VPN Layer 2 Virtual Private Network
L2SM L2VPN Service Model
L2NM L2VPN Network Model
PE Provider Edge
QoS Quality of Service
RD Route Distinguisher
RT Route Target
VPN Virtual Private Network
VRF Virtual Routing and Forwarding
4. Reference Architecture
Figure 1 illustrates how 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".
Barguil, et al. Expires November 1, 2021 [Page 5]
Internet-Draft L2NM April 2021
+---------------+
| Customer |
+-------+-------+
Customer Service Model |
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
Figure 1: L2SM and L2NM Interaction
Barguil, et al. Expires November 1, 2021 [Page 6]
Internet-Draft L2NM April 2021
The customer may use a variety of means to request a service that may
trigger the instantiation of a L2NM. The customer may use the L2SM
or may rely upon more abstract models to request a service that
relies upon an L3VPN 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).
Barguil, et al. Expires November 1, 2021 [Page 7]
Internet-Draft L2NM April 2021
+----------------------------------+
| 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 |
+--------+ +--------+
Figure 2: L2SM and L2NM in the Context of ACTN
5. Relation with other YANG Models
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
Barguil, et al. Expires November 1, 2021 [Page 8]
Internet-Draft L2NM April 2021
model) including future revisions of existing models (e.g.,
[RFC8466]). The L2NM reuses these common types and groupings.
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:
L2SM: 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. Some other parts are local to the service
provider and do not map directly to L2SM.
Note that the use of 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.
Network Topology Modules: An L2VPN involves nodes that are part of a
topology managed by the service provider network. Such topology
can be represented using the network topology module in [RFC8345].
Device Modules: 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.
How the L2NM is used to derive device-specific actions is
implementation-specific.
Barguil, et al. Expires November 1, 2021 [Page 9]
Internet-Draft L2NM April 2021
6. Description of the L2NM YANG Module
The L2NM module ('ietf-l2vpn-ntw') is meant to manage L2VPNs within a
service provider network. In particular, the 'ietf-l2vpn-ntw' module
can be used to create, modify, and retrieve L2VPN services in a
network controller. The module is not aimed at maintaining customer-
related information.
Editor's note: Next version of the document will include the full
description of the parameters. When the parameters match with L2SM,
the exact reference will be done
6.1. Structure of the Module
The 'ietf-l2vpn-ntw' module uses two main containers: 'vpn-services'
and 'vpn-profiles'. The 'vpn-services' container maintains a set of
L2VPN services managed in the service providers network. The module
allows to create a new L2VPN service by adding a new instance of
'vpn-service'. The 'vpn-service' is the data structure that
abstracts the VPN Service.
module: ietf-l3vpn-ntw
+--rw l3vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
...
Figure 3: Simplified L2NM Tree Structure
6.2. VPN Profiles
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.
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
Barguil, et al. Expires November 1, 2021 [Page 10]
Internet-Draft L2NM April 2021
policies when building a VPN service. As shown in Figure 4, the
following identifiers can be included:
'external-connectivity-identifier': This identifier refers to a
profile that defines the external connectivity provided to a VPN
service (or a subset of VPN sites). An external connectivity may
be an access to the Internet or a restricted connectivity such as
access to a public/private cloud.
'encryption-profile-identifier': An encryption profile refers to a
set of policies related to the encryption schemes and setup that
can be applied when building and offering a VPN service.
'qos-profile-identifier': A Quality of Service (QoS) profile refers
to as set of policies such as classification, marking, and actions
(e.g., [RFC3644]).
'bfd-profile-identifier': A Bidirectional Forwarding Detection (BFD)
profile refers to a set of BFD [RFC5880] policies that can be
invoked when building a VPN service.
'forwarding-profile-identifier': A forwarding profile refers to the
policies that apply to the forwarding of packets conveyed within a
VPN. Such policies may consist, for example, at applying Access
Control Lists (ACLs).
'routing-profile-identifier': A routing profile refers to a set of
routing policies that will be invoked (e.g., BGP policies) when
delivering the VPN service.
Barguil, et al. Expires November 1, 2021 [Page 11]
Internet-Draft L2NM April 2021
+--rw l2vpn-ntw
+--rw vpn-profiles
| +--rw valid-provider-identifiers
| +--rw external-connectivity-identifier* [id]
| | {external-connectivity}?
| | +--rw id string
| +--rw encryption-profile-identifier* [id]
| | +--rw id string
| +--rw qos-profile-identifier* [id]
| | +--rw id string
| +--rw bfd-profile-identifier* [id]
| | +--rw id string
| +--rw forwarding-profile-identifier* [id]
| | +--rw id string
| +--rw routing-profile-identifier* [id]
| +--rw id string
+--rw vpn-services
...
Figure 4: VPN Profiles Subtree Structure
6.3. L2VPN Service
The 'vpn-service' is the data structure that abstracts a VPN 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 5.
Barguil, et al. Expires November 1, 2021 [Page 12]
Internet-Draft L2NM April 2021
+--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 global-parameters-profiles
| +--rw global-parameters-profile* [profile-id]
| +--rw profile-id string
| +--rw svc-mtu? uint32
| +--rw ce-vlan-preservation? boolean
| +--rw ce-vlan-cos-perservation? 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 frequency? uint32
| | +--rw protection-type? identityref
| | +--rw number-retries? uint32
| +--rw multicast-like {vpn-common:multicast}?
| +--rw enabled? boolean
| +--rw customer-tree-flavors
| +--rw tree-flavor* identityref
+--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-updated? yang:date-and-time
| +--ro oper-status
| +--ro status? identityref
| +--ro last-updated? yang:date-and-time
+--rw vpn-nodes
...
Figure 5
Barguil, et al. Expires November 1, 2021 [Page 13]
Internet-Draft L2NM April 2021
The description of the VPN service data nodes that are depicted in
Figure 5 are as follows:
'vpn-id': Is an identifier that is used to uniquely identify the
L2VPN service within L2NM scope.
'vpn-name': Associates a name with the service in order to
facilitate the identification of the service.
'vpn-description': Includes a textual description of the service.
The internal structure of a VPN description is local to each VPN
service provider.
'customer-name': Indicates the name of the customer who ordered the
service.
'parent-service-id': Refers to an identifier of the parent service
(e.g, L2SM, IETF network slice, VPN+) that triggered the creation
of the VPN service. This identifier is used to easily correlate
the (network) service as built in the network with a service
order. A controller can use that correlation to enrich or
populate some fields (e.g., description fields) as a function of
local deployments.
'vpn-type': Indicates the VPN type. Typically, the following types
can be used for the L2NM [I-D.ietf-opsawg-vpn-common]:
'vpls': Virtual Private LAN Service (VPLS) as defined in
[RFC4761] or [RFC4762].
'vpws-evpn': Point-to-point Virtual Private Wire Service (VPWS)
as defined in [RFC8214].
'pbb-evpn': Provider Backbone Bridging (PBB) EVPNs as defined in
[RFC7623].
'mpls-evpn': MPLS-based EVPNs [RFC7432].
'vxlan-evpn': VXLAN based EVPNs [RFC8365].
'vpn-service-topology': Indicates the network topology for the
service: hub-spoke, any-to-any, or custom.
'global-parameters-profiles': Defines reusable parameters for the
same 'vpn-service'.
More details are provided in Section 6.3.1.
Barguil, et al. Expires November 1, 2021 [Page 14]
Internet-Draft L2NM April 2021
'underlay-transport': Describes the preference for the transport
technology to carry the traffic of the VPN service. This
preference is especially useful in networks with multiple domains
and Network-to-Network Interface (NNI) types. The underlay
transport can be expressed as an abstract transport instance
(e.g., an identifier of a VPN+ instance, a virtual network
identifier, or a network slice name) or as an ordered list of the
actual protocols to be enabled in the network.
A rich set of protocol identifiers that can be used to refer to an
underlay transport are defined in [I-D.ietf-opsawg-vpn-common].
'status': 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.
'vpn-node': Is an abstraction that represents a set of policies
applied to a network node and that belong to a single 'vpn-
service'. A VPN 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.3.2.
6.3.1. Global Parameters Profiles
TBC
Barguil, et al. Expires November 1, 2021 [Page 15]
Internet-Draft L2NM April 2021
6.3.2. VPN Node
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'.
Barguil, et al. Expires November 1, 2021 [Page 16]
Internet-Draft L2NM April 2021
+--rw l2vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
+--rw vpn-node-id vpn-common:vpn-id
+--rw description? string
+--rw role? identityref
+--rw ne-id string
+--rw active-global-parameters-profiles
| +--rw global-parameters-profile* [profile-id]
| +--rw profile-id leafref
| +--rw svc-mtu? uint32
| +--rw ce-vlan-preservation? boolean
| +--rw ce-vlan-cos-perservation? 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 frequency? uint32
| | +--rw protection-type? identityref
| | +--rw number-retries? uint32
| +--rw multicast-like {vpn-common:multicast}?
| +--rw enabled? boolean
| +--rw customer-tree-flavors
| +--rw tree-flavor* identityref
+--rw status
| +--rw admin-status
| | +--rw status? identityref
| | +--rw last-updated? yang:date-and-time
| +--ro oper-status
| +--ro status? identityref
| +--ro last-updated? yang:date-and-time
+--rw signaling-options* [type]
| ...
+--rw vpn-network-accesses
...
Figure 6
In reference to the subtree shown in Figure 6, the description of VPN
node data nodes is as follows:
Barguil, et al. Expires November 1, 2021 [Page 17]
Internet-Draft L2NM April 2021
'vpn-node-id': Is an identifier that uniquely identifies a node that
enables a VPN network access.
'description': Provides a textual description of the VPN node.
'ne-id': Includes a unique identifier of the network element where
the VPN node is deployed.
'active-global-parameters-profiles': 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' is the same as the one
discussed in Section 6.3.1.
Values defined in 'active-global-parameters-profiles' overrides
the ones defined in the VPN service level.
'signaling-options': See Section 6.3.2.1.
'status': Tracks the status of a node involved in a VPN service.
Both operational and administrative status are maintained. A
mismatch between the administrative status vs. the operational
status can be used as a trigger to detect anomalies.
'vpn-network-accesses': 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.3.2.2 for more details.
6.3.2.1. Signaling Options
This sub-tree defines the L2VPN service type, according to the
several signalling options to exchange membership information between
PEs of an L2VPN. The following signaling options are supported:
'l2vpn-bgp': Refers to the BGP control plane as described in
[RFC4761] and [RFC6624].
Barguil, et al. Expires November 1, 2021 [Page 18]
Internet-Draft L2NM April 2021
'evpn-bgp': Refers to the BGP control plane as described in
[RFC7432] and [RFC7209].
't-ldp-pwe': Refers to LDP-signaled Pseudowires [RFC6074].
'l2tp-pwe': Refers to L2TP-signaled Pseudowires [RFC6074].
+--------------+---------------------+
| Service Type | Signaling Options |
+--------------+---------------------+
| vpls | t-ldp-pwe, l2tp-pwe |
| vpws-evpn | evpn-bgp |
| pbb-evpn | evpn-bgp |
| mpls-evpn | l2vpn-bgp, evpn-bgp |
| vxlan-evpn | evpn-bgp |
+--------------+---------------------+
Table 1: Valid Signaling Options per Service Type (To be completed)
...
+--rw signaling-options* [type]
| +--rw type identityref
| +--rw (signaling-option)?
| +--:(bgp)
| | +--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)
Barguil, et al. Expires November 1, 2021 [Page 19]
Internet-Draft L2NM April 2021
| | | +--rw no-rd? empty
| | +--rw vpn-target* [id]
| | | +--rw id int8
| | | +--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 address-family? identityref
| | +--rw (l2vpn-bgp)?
| | | +--:(pwe-encapsulation-type)
| | | | +--rw pwe-encapsulation-type? identityref
| | | +--:(pwe-mtu)
| | | +--rw pwe-mtu
| | | +--rw allow-mtu-mismatch? boolean
| | +--rw (evpn-bgp)?
| | +--:(vpn-id)
| | | +--rw vpn-id? leafref
| | +--:(evpn-type)
| | | +--rw evpn-type? identityref
| | +--:(service-interface-type)
| | | +--rw service-interface-type? identityref
| | +--:(common)
| | +--rw common
| | +--rw mac-learning-mode? identityref
| | +--rw ingress-replication? boolean
| | +--rw p2mp-replication? boolean
| | +--rw arp-proxy? boolean
| | +--rw arp-suppression? boolean
| | +--rw nd-proxy? boolean
| | +--rw nd-suppression? boolean
| | +--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)
| | +--rw t-ldp-pwe-type? identityref
| | +--rw encapsulation-type? identityref
| | +--rw mtu-pwe? uint16
| | +--rw ac-pw-list* [peer-addr vc-id]
| | | +--rw peer-addr inet:ip-address
| | | +--rw vc-id vpn-common:vpn-id
Barguil, et al. Expires November 1, 2021 [Page 20]
Internet-Draft L2NM April 2021
| | | +--rw pw-type? identityref
| | | +--rw pw-priority? uint32
| | +--rw qinq
| | +--rw s-tag? uint32
| | +--rw c-tag? uint32
| +--:(l2tp-pwe)
| +--rw TBD-type? identityref
| +--rw XXXencapsulation-type? identityref
| +--rw XXXXac-pw-list* [peer-addr vc-id]
| +--rw peer-addr inet:ip-address
| +--rw vc-id string
| +--rw pw-priority? uint32
...
Figure 7
6.3.2.2. VPN Network Access
A 'vpn-network-access' 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.
The VPN network access is comprised of:
'id': Identifier of the VPN network access.
'description': Text describing the VPN network access.
'status': Administrative and operational status of the service.
'ethernet-service-oam': Carries information about the service OAM.
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
+--rw id vpn-common:vpn-id
+--rw description? string
+--rw port-id? vpn-common:vpn-id
+--rw global-parameters-profile? leafref
+--rw status
| +--rw admin-status
| | +--rw status? identityref
| | +--rw last-updated? yang:date-and-time
Barguil, et al. Expires November 1, 2021 [Page 21]
Internet-Draft L2NM April 2021
| +--ro oper-status
| +--ro status? identityref
| +--ro last-updated? yang:date-and-time
+--rw connection
| ...
+--rw TO-SIMPLFY-diversity-redundancy-TO-SIMPLFY
| +--rw access-diversity {vpn-common:placement-diversity}?
| | +--rw groups
| | +--rw group* [group-id]
| | +--rw group-id string
| | +--rw fate-sharing-group-size? uint16
| | +--rw group-color? string
| | +--rw ethernet-segment-identifier? yang:hex-string
| | +--rw esi-redundancy-mode? identityref
| +--rw constraints
| | +--rw constraint* [constraint-type]
| | +--rw constraint-type identityref
| | +--rw target
| | +--rw (target-flavor)?
| | +--:(id)
| | | +--rw group* [group-id]
| | | +--rw group-id string
| | +--:(all-accesses)
| | | +--rw all-other-accesses? empty
| | +--:(all-groups)
| | +--rw all-other-groups? empty
| +--rw availability
| | +--rw access-priority? uint32
| | +--rw (redundancy-mode)?
| | +--:(single-active)
| | | +--rw single-active? boolean
| | +--:(all-active)
| | +--rw all-active? boolean
| +--rw precedence
| +--rw precedence? identityref
+--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
Barguil, et al. Expires November 1, 2021 [Page 22]
Internet-Draft L2NM April 2021
| | | +--rw ccm-p-bits-pri?
| | | vpn-common: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?
| | vpn-common:ccm-priority-type
| +--rw y-1731* [maid]
| +--rw maid string
| +--rw mep-id? uint32
| +--rw 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
...
Figure 8
6.3.2.2.1. Connection
The connection container is used to configure the relevant properties
of the interface that is attached to the VPN, for example the
encapsulation type, the physical interface or creating a lag.
+--rw connection
+--rw encapsulation-type? identityref
+--rw eth-inf-type* identityref
+--rw dot1q-interface
| +--rw l2-access-type? identityref
| +--rw dot1q {vpn-common:dot1q}?
| | +--rw physical-inf? string
Barguil, et al. Expires November 1, 2021 [Page 23]
Internet-Draft L2NM April 2021
| | +--rw c-vlan-id? uint32
| +--rw qinq {vpn-common:qinq}?
| | +--rw s-vlan-id? uint32
| | +--rw c-vlan-id? uint32
| +--rw qinany {vpn-common:qinany}?
| | +--rw s-vlan-id? uint32
| +--rw vxlan {vxlan}?
| +--rw vni-id? uint32
| +--rw peer-mode? identityref
| +--rw peer-list* [peer-ip]
| +--rw peer-ip inet:ip-address
+--rw phy-interface
| +--rw port-number? uint32
| +--rw port-speed? uint32
| +--rw mode?
| | vpn-common:neg-mode
| +--rw phy-mtu? uint32
| +--rw flow-control? string
| +--rw oam-802.3ah-link {oam-3ah}?
| | +--rw enable? boolean
| +--rw uni-loop-prevention? boolean
+--rw lag-interface
| {vpn-common:lag-interface}?
| +--rw lag-interface*
| [lag-interface-number]
| +--rw lag-interface-number uint32
| +--rw lacp
| +--rw lacp-state? boolean
| +--rw lacp-mode? boolean
| +--rw lacp-speed? boolean
| +--rw mini-link? uint32
| +--rw system-priority? uint16
| +--rw member-link-list
| | +--rw member-link* [name]
| | +--rw name string
| | +--rw port-speed?
| | | uint32
| | +--rw mode?
| | | vpn-common:neg-mode
| | +--rw link-mtu? uint32
| | +--rw oam-802.3ah-link
| | {oam-3ah}?
| | +--rw enable? boolean
| +--rw flow-control? string
| +--rw lldp? boolean
+--rw cvlan-id-to-svc-map* [svc-id]
| +--rw svc-id leafref
| +--rw cvlan-id* [vid]
Barguil, et al. Expires November 1, 2021 [Page 24]
Internet-Draft L2NM April 2021
| +--rw vid uint32
+--rw split-horizon
+--rw group-name? string
Figure 9
6.3.2.2.2. Services
This container is used to indicate the details of the ethernet
service such as bandwidth or qos.
+--rw service
+--rw mtu? uint32
+--rw svc-input-bandwidth {vpn-common:input-bw}?
| +--rw input-bandwidth* [type]
| +--rw type identityref
| +--rw cos-id? uint8
| +--rw cir? uint64
| +--rw cbs? uint64
| +--rw eir? uint64
| +--rw ebs? uint64
| +--rw pir? uint64
| +--rw pbs? uint64
+--rw svc-output-bandwidth {output-bw}?
| +--rw output-bandwidth* [type]
| +--rw type identityref
| +--rw cos-id? uint8
| +--rw cir? uint64
| +--rw cbs? uint64
| +--rw eir? uint64
| +--rw ebs? uint64
| +--rw pir? uint64
| +--rw pbs? uint64
+--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? yang:mac-address
| | | | +--rw dst-mac? yang:mac-address
| | | | +--rw color-type? identityref
| | | | +--rw any? empty
| | | +--:(match-application)
Barguil, et al. Expires November 1, 2021 [Page 25]
Internet-Draft L2NM April 2021
| | | +--rw match-application? identityref
| | +--rw target-class-id? string
| +--rw qos-profile
| +--rw qos-profile* [profile]
| +--rw profile leafref
| +--rw direction? identityref
+--rw mac-policies
| +--rw access-control-list
| | +--rw mac* [mac-address]
| | +--rw mac-address yang:mac-address
| +--rw mac-loop-prevention
| | +--rw frequency? uint32
| | +--rw protection-type? identityref
| | +--rw number-retries? uint32
| +--rw mac-addr-limit
| +--rw mac-num-limit? uint16
| +--rw time-interval? uint32
| +--rw action? identityref
+--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
Figure 10
7. YANG Module
<CODE BEGINS>file "ietf-l2vpn-ntw@2021-04-29.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
"Section 4 of RFC 6991";
}
import ietf-yang-types {
prefix yang;
reference
"Section 3 of RFC 6991";
}
import ietf-vpn-common {
Barguil, et al. Expires November 1, 2021 [Page 26]
Internet-Draft L2NM April 2021
prefix vpn-common;
reference
"RFC CCCC: A Layer 2/3 VPN Common YANG Model";
}
organization
"IETF OPSA (Operations and Management Area) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>
Editor: Samier Barguil
<mailto:samier.barguilgiraldo.ext@telefonica.com>
Editor: Oscar Gonzalez de Dios
<mailto:oscar.gonzalezdedios@telefonica.com>
Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>";
description
"This YANG module defines a generic 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-04-29 {
description
"Initial version.";
reference
"RFC XXXX: A Layer 2 VPN Network YANG Model.";
}
/* Features */
feature multicast-like {
description
"Indicates the support of multicast-like capabilities
in a L2VPN.";
}
Barguil, et al. Expires November 1, 2021 [Page 27]
Internet-Draft L2NM April 2021
feature target-sites {
description
"Indicates the support of 'target-sites' match flow
parameter.";
}
feature l2cp-control {
description
"Indicates the support of L2CP control.";
}
feature output-bw {
description
"Indicates the support of Output Bandwidth in
a VPN";
}
feature uni-list {
description
"Indicates thesupport of UNI list in a VPN.";
}
feature oam-3ah {
description
"Indicates the support of OAM 802.3ah.";
}
feature micro-bfd {
description
"Indicates the support of Micro-BFD.";
}
feature signaling-options {
description
"Indicates the support of signalling option.";
}
feature always-on {
description
"Indicates the support for always-on access
constraint.";
}
feature requested-type {
description
"Indicates the support for requested-type access
constraint.";
}
Barguil, et al. Expires November 1, 2021 [Page 28]
Internet-Draft L2NM April 2021
feature vlan {
description
"Indicates the support of VLAN.";
}
feature sub-inf {
description
"Indicates the support of Sub Interface.";
}
feature atm {
description
"Indicates the support of ATM.";
}
feature vxlan {
description
"Indicates the support of VxLAN.";
}
feature lan-tag {
description
"Indicates the LAN Tag support in a VPN.";
}
/* Typedefs */
/* Identities */
identity evpn-redundancy-mode {
description
"Base identity for EVPN redundancy modes.";
}
identity single-active {
base evpn-redundancy-mode;
description
"Indicates Single-Active redundancy mode for
a given Ethernet Segment (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 Ethernet Segment (ES).";
reference
Barguil, et al. Expires November 1, 2021 [Page 29]
Internet-Draft L2NM April 2021
"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-redundancy-mode;
description
"VLAN-Based Service Interface.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.1";
}
identity vlan-bundle-service-interface {
base evpn-redundancy-mode;
description
"VLAN Bundle Service Interface.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.2";
}
identity vlan-aware-bundle-service-interface {
base evpn-redundancy-mode;
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 mapping type.";
}
identity protection-mode {
description
"Identity of protection mode";
}
identity oneplusone {
base protection-mode;
description
"In this scheme, the primary circuit will be
protected by a backup circuit, typically meeting certain
Barguil, et al. Expires November 1, 2021 [Page 30]
Internet-Draft L2NM April 2021
diverse path/fiber/site/node criteria. Both primary and
protection circuits are provisioned to be in the active
forward ing state. The subscriber may choose to send the
same service frames across both circuits simultaneously.";
}
identity one-to-one {
base protection-mode;
description
"In this scheme, a backup circuit to the primary
circuit is provisioned. Depending on the implementation
agreement, the protection circuits may either always be
in active forwarding state, or may only become active when
a faulty state is detected on the primary circuit.";
}
identity bundling-type {
description
"The base identity for the bundling type. It supports
multiple CE-VLANs associated with an L2VPN service or
all CE-VLANs associated with an L2VPN service.";
}
identity multi-svc-bundling {
base bundling-type;
description
"Identity for multi-service bundling, i.e.,
multiple CE-VLAN IDs can be associated with an
L2VPN service at a site.";
}
identity one2one-bundling {
base bundling-type;
description
"Identity for one-to-one service bundling, i.e.,
each L2VPN can be associated with only one CE-VLAN ID
at a site.";
}
identity all2one-bundling {
base bundling-type;
description
"Identity for all-to-one bundling, i.e., all CE-VLAN IDs
are mapped to one L2VPN service.";
}
identity color-id {
description
Barguil, et al. Expires November 1, 2021 [Page 31]
Internet-Draft L2NM April 2021
"Base identity of the color ID.";
}
identity color-id-cvlan {
base color-id;
description
"Identity of the color ID based on a CVLAN.";
}
identity color-type {
description
"Identity of color types.";
}
identity green {
base color-type;
description
"Identity of the 'green' color type.";
}
identity yellow {
base color-type;
description
"Identity of the 'yellow' color type.";
}
identity red {
base color-type;
description
"Identity of the 'red' color type.";
}
identity perf-tier-opt {
description
"Identity of performance tier option.";
}
identity metro {
base perf-tier-opt;
description
"Identity of metro";
}
identity regional {
base perf-tier-opt;
description
"Identity of regional";
}
Barguil, et al. Expires November 1, 2021 [Page 32]
Internet-Draft L2NM April 2021
identity continental {
base perf-tier-opt;
description
"Identity of continental";
}
identity global {
base perf-tier-opt;
description
"Identity of global";
}
identity policing {
description
"Identity of policing type";
}
identity one-rate-two-color {
base policing;
description
"Identity of one-rate, two-color (1R2C)";
}
identity two-rate-three-color {
base policing;
description
"Identity of two-rate, three-color (2R3C)";
}
identity loop-prevention-type {
description
"Identity of loop prevention.";
}
identity shut {
base loop-prevention-type;
description
"Identity of shut protection.";
}
identity trap {
base loop-prevention-type;
description
"Identity of trap protection.";
}
identity t-ldp-pwe-type {
description
Barguil, et al. Expires November 1, 2021 [Page 33]
Internet-Draft L2NM April 2021
"Identity for t-ldp-pwe-type.";
}
identity vpws-type {
base t-ldp-pwe-type;
description
"Identity for VPWS";
}
identity vpls-type {
base t-ldp-pwe-type;
description
"Identity for vpls";
}
identity hvpls {
base t-ldp-pwe-type;
description
"Identity for h-vpls";
}
identity l2vpn-type {
description
"Layer 2 VPN types";
}
identity l2vpn-vpws {
base l2vpn-type;
description
"VPWS L2VPN type.";
}
identity l2vpn-vpls {
base l2vpn-type;
description
"VPLS L2VPN type.";
}
identity distribute-vpls {
base l2vpn-type;
description
"distribute VPLS L2VPN type.";
}
identity evpn-type {
description
"Ethernet VPN types";
}
Barguil, et al. Expires November 1, 2021 [Page 34]
Internet-Draft L2NM April 2021
identity evpn-vpws {
base evpn-type;
description
"VPWS support in EVPN.";
}
identity evpn-pbb {
base evpn-type;
description
" Provider Backbone Bridging Support in EVPN.";
}
identity pm-type {
description
"Performance-monitoring type.";
}
identity loss {
base pm-type;
description
"Loss measurement.";
}
identity delay {
base pm-type;
description
"Delay measurement.";
}
identity mac-learning-mode {
description
"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
Barguil, et al. Expires November 1, 2021 [Page 35]
Internet-Draft L2NM April 2021
"Base identity for a MAC action.";
}
identity drop {
base mac-action;
description
"Identity for dropping a packet.";
}
identity flood {
base mac-action;
description
"Identity for packet flooding.";
}
identity warning {
base mac-action;
description
"Identity for sending a warning log message.";
}
identity load-balance-method {
description
"Base identity for load balance method.";
}
identity fat-pw {
base load-balance-method;
description
"Identity for Fat PW. Fat label is
applied to Pseudowires across MPLS
network.";
}
identity entropy-label {
base load-balance-method;
description
"Identity for entropy label.Entropy label
is applied to IP forwarding,
L2VPN or L3VPN across MPLS network";
}
identity vxlan-source-port {
base load-balance-method;
description
"Identity for vxlan source port.VxLAN
Source Port is one load balancing method.";
}
Barguil, et al. Expires November 1, 2021 [Page 36]
Internet-Draft L2NM April 2021
identity precedence-type {
description
"Redundancy type. The service can be created
with active and bakcup signalization.";
}
identity primary {
base precedence-type;
description
"Identifies the Main L2VPN.";
}
identity backup {
base precedence-type;
description
"Identifies the Backup L2VPN.";
}
/* Groupings */
grouping cfm-802-grouping {
description
"Grouping for 802.1ag CFM attribute";
leaf maid {
type string;
description
"MA ID";
}
leaf mep-id {
type uint32;
description
"Local MEP ID";
}
leaf mep-level {
type uint32;
description
"MEP level";
}
leaf mep-up-down {
type enumeration {
enum up {
description
"MEP up";
}
enum down {
description
"MEP down";
}
Barguil, et al. Expires November 1, 2021 [Page 37]
Internet-Draft L2NM April 2021
}
description
"MEP up/down";
}
leaf remote-mep-id {
type uint32;
description
"Remote MEP ID";
}
leaf cos-for-cfm-pdus {
type uint32;
description
"COS for CFM PDUs";
}
leaf ccm-interval {
type uint32;
description
"CCM interval";
}
leaf ccm-holdtime {
type uint32;
description
"CCM hold time";
}
leaf ccm-p-bits-pri {
type vpn-common:ccm-priority-type;
description
"The priority parameter for CCMs transmitted by the MEP";
}
}
grouping y-1731 {
description
"Grouping for y.1731";
list y-1731 {
key "maid";
description
"List for y-1731.";
leaf maid {
type string;
description
"MA ID ";
}
leaf mep-id {
type uint32;
description
"Local MEP ID";
}
Barguil, et al. Expires November 1, 2021 [Page 38]
Internet-Draft L2NM April 2021
leaf 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;
description
"Defines the interval between OAM messages. The message
period is expressed in milliseconds";
}
leaf measurement-interval {
type uint32;
description
"Specifies the measurement interval for statistics. The
measurement interval is expressed in seconds";
}
leaf cos {
type uint32;
description
"Class of service";
}
leaf loss-measurement {
type boolean;
description
"Whether enable loss measurement";
}
leaf synthethic-loss-measurement {
type boolean;
description
"Indicate whether enable synthetic loss measurement";
}
container delay-measurement {
description
"Container for delay measurement";
leaf enable-dm {
type boolean;
description
"Whether to enable delay measurement";
}
leaf two-way {
Barguil, et al. Expires November 1, 2021 [Page 39]
Internet-Draft L2NM April 2021
type boolean;
description
"Whether delay measurement is two-way (true) of one-
way (false)";
}
}
leaf frame-size {
type uint32;
description
"Frame size";
}
leaf session-type {
type enumeration {
enum proactive {
description
"Proactive mode";
}
enum on-demand {
description
"On demand mode";
}
}
description
"Session type";
}
}
}
///
grouping global-parameters-profile {
description
"Container for per-service paramters.";
leaf svc-mtu {
type uint32;
description
"SVC 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";
}
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
Barguil, et al. Expires November 1, 2021 [Page 40]
Internet-Draft L2NM April 2021
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-perservation {
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 RFC8077";
}
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.";
}
}
Barguil, et al. Expires November 1, 2021 [Page 41]
Internet-Draft L2NM April 2021
container mac-loop-prevention {
description
"Container of MAC loop prevention.";
leaf frequency {
type uint32;
description
"Frequency";
}
leaf protection-type {
type identityref {
base loop-prevention-type;
}
description
"Protection type";
}
leaf number-retries {
type uint32;
description
"Number of retries";
}
}
}
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 tree to be used.";
}
}
}
}
/* Main L2NM Container */
Barguil, et al. Expires November 1, 2021 [Page 42]
Internet-Draft L2NM April 2021
container l2vpn-ntw {
description
"Container for L2NM.";
container vpn-profiles {
description
"Container for VPN profiles.";
uses vpn-common:vpn-profile-cfg;
}
container vpn-services {
description
"Container for L2VPN service";
list vpn-service {
key "vpn-id";
description
"Container of port configurations";
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-svc-type {
type identityref {
base vpn-common:service-type;
}
description
"Service type";
}
leaf svc-topo {
type identityref {
base vpn-common:vpn-topology;
}
description
"Defining service topology, such as
any-to-any, hub-spoke, etc.";
}
container global-parameters-profiles {
description
"Container for a list of VPN instance profiles.";
list global-parameters-profile {
key "profile-id";
description
"List of XXX.";
leaf profile-id {
type string;
description
"profile identifier.";
Barguil, et al. Expires November 1, 2021 [Page 43]
Internet-Draft L2NM April 2021
}
uses global-parameters-profile;
}
}
container underlay-transport {
description
"Container for underlay transport.";
uses vpn-common:underlay-transport;
}
uses vpn-common:service-status;
container vpn-nodes {
description
"Set fo VPN nodes that are involved in the L2NM.";
list vpn-node {
key "vpn-node-id";
description
"Container of VPN Nodes.";
leaf vpn-node-id {
type vpn-common:vpn-id;
description
"VPN Node indentifier";
}
leaf description {
type string;
description
"Textual description of a VPN node.";
}
leaf ne-id {
type string;
description
"NE 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.";
}
container active-global-parameters-profiles {
description
"Container for a list of VPN instance profiles.";
list global-parameters-profile {
key "profile-id";
description
"List of XXX.";
leaf profile-id {
Barguil, et al. Expires November 1, 2021 [Page 44]
Internet-Draft L2NM April 2021
type leafref {
path "/l2vpn-ntw/vpn-services/vpn-service"
+ "/global-parameters-profiles"
+ "/global-parameters-profile/profile-id";
}
description
"XXXX.";
}
uses global-parameters-profile;
}
}
uses vpn-common:service-status;
list signaling-options {
key "type";
description
"List of VPN signaling options.";
leaf type {
type identityref {
base vpn-common:vpn-signaling-type;
}
description
"VPN signaling types.";
}
choice signaling-option {
description
"Choice for the signaling-option.";
case bgp {
when "./type = 'vpn-common:bgp-signaling'" {
description
"Only applies when VPN signaling type is
BGP.";
}
description
"xxx.";
uses vpn-common:route-distinguisher;
uses vpn-common:vpn-route-targets;
choice l2vpn-bgp {
description
"Container for MP BGP L2VPN.";
leaf pwe-encapsulation-type {
type identityref {
base vpn-common:encapsulation-type;
}
description
"PWE encapsulation type.";
}
container pwe-mtu {
description
Barguil, et al. Expires November 1, 2021 [Page 45]
Internet-Draft L2NM April 2021
"Container of PWE MTU configurations.";
leaf allow-mtu-mismatch {
type boolean;
description
"When set to true, it allows MTU mismatch.";
}
}
}
choice evpn-bgp {
description
"Container for MP BGP L2VPN.";
leaf evpn-type {
type identityref {
base evpn-type;
}
description
"EVPN type.";
}
leaf service-interface-type {
type identityref {
base evpn-service-type;
}
description
"EVPN service interface type.";
}
container common {
description
"MAC address managment attributes in the
EVPN configuration";
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
"ingress-replication";
}
leaf p2mp-replication {
type boolean;
description
"p2mp-replication";
}
leaf arp-proxy {
Barguil, et al. Expires November 1, 2021 [Page 46]
Internet-Draft L2NM April 2021
type boolean;
default "false";
description
"Enable (TRUE) or disable (FALSE) ARP proxy";
}
leaf arp-suppression {
type boolean;
default "false";
description
"Enable (TRUE) or disable (FALSE) ARP suppression";
}
leaf nd-proxy {
type boolean;
default "false";
description
"Enable (TRUE) or disable (FALSE) ND proxy";
}
leaf nd-suppression {
type boolean;
default "false";
description
"Enable (TRUE) or disable (FALSE) ND suppression";
}
leaf underlay-multicast {
type boolean;
default "false";
description
"Enable (TRUE) or disable (FALSE) underlay multicast";
}
leaf flood-unknown-unicast-supression {
type boolean;
default "false";
description
"Enable (TRUE) or disable (FALSE) flood unknown
unicast suppression";
}
leaf vpws-vlan-aware {
type boolean;
default "false";
description
"Enable (True) or disable (False) VPWS VLAN aware";
}
container bum-management {
description
"broadcast-unknown-unicast-multicast management";
leaf discard-broadcast {
type boolean;
description
Barguil, et al. Expires November 1, 2021 [Page 47]
Internet-Draft L2NM April 2021
"Broadcast management.";
}
leaf discard-unknown-multicast {
type boolean;
description
"Broadcast management.";
}
leaf discard-unknown-unicast {
type boolean;
description
"Unicast management.";
}
}
container pbb {
description
"PBB parameters container";
reference
"IEEE 802.1ah Provider Backbone Bridge";
leaf backbone-src-mac {
type yang:mac-address;
description
"backbone-src-mac";
}
}
}
}
}
case ldp {
when "./type = 'ldp-signaling'" {
description
"Only applies when vpn signaling type is Target LDP.";
}
description
"Container of T-LDP PWE configurations";
leaf t-ldp-pwe-type {
type identityref {
base t-ldp-pwe-type;
}
description
"T-LDP PWE type";
}
leaf encapsulation-type {
type identityref {
base vpn-common:encapsulation-type;
}
description
"PWE encapsulation type.";
}
Barguil, et al. Expires November 1, 2021 [Page 48]
Internet-Draft L2NM April 2021
leaf mtu-pwe {
type uint16;
description
"Allow MTU mismatch: TO BE CHECKED";
}
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 vpn-common:vpn-id;
description
"VC lable used to identify PW.";
}
leaf pw-type {
type identityref {
base vpn-common:vpn-topology;
}
description
"PW topology type.";
}
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 "../type = 'vpn-common:h-vpls'" {
description
"Only applies when t-ldp pwe type is h-vpls.";
}
description
"Container for QinQ";
leaf s-tag {
type uint32;
description
"S-TAG";
}
leaf c-tag {
type uint32;
Barguil, et al. Expires November 1, 2021 [Page 49]
Internet-Draft L2NM April 2021
description
"C-TAG";
}
}
}
case l2tp-pwe {
when "./type = 'l2tp-signaling'" {
description
"Applies when VPN signaling type is L2TP protocol.";
}
description
"Container for l2tp pw";
leaf TBD-type {
type identityref {
base t-ldp-pwe-type;
}
description
"T-LDP PWE type.";
}
leaf XXXencapsulation-type {
type identityref {
base vpn-common:encapsulation-type;
}
description
"Encapsulation type.";
}
list XXXXac-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 lable used to identify PW.";
}
leaf pw-priority {
type uint32;
description
"PW priority.";
}
}
}
}
Barguil, et al. Expires November 1, 2021 [Page 50]
Internet-Draft L2NM April 2021
}
container vpn-network-accesses {
description
"List of VPN Nodes.";
list vpn-network-access {
key "id";
description
"List of VPN Network Accesses.";
leaf id {
type vpn-common:vpn-id;
description
"Identifier of network access";
}
leaf description {
type string;
description
"String to describe the element.";
}
leaf port-id {
type vpn-common:vpn-id;
description
"NE Port-id";
}
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 bearer";
leaf encapsulation-type {
type identityref {
base vpn-common:encapsulation-type;
}
description
"Encapsulation Type";
}
leaf-list eth-inf-type {
type identityref {
base vpn-common:encapsulation-type;
}
description
Barguil, et al. Expires November 1, 2021 [Page 51]
Internet-Draft L2NM April 2021
"Ethernet interface type.";
}
container encapsulation {
description
"Container for dot1Q Interface";
leaf l2-access-type {
type identityref {
base vpn-common:encapsulation-type;
}
description
"L2 Access encapsulation type.";
}
container dot1q {
when "../l2-access-type='vpn-common:dot1q'";
if-feature "vpn-common:dot1q";
description
"Qot1q";
leaf physical-inf {
type string;
description
"Physical Interface";
}
leaf c-vlan-id {
type uint32;
description
"VLAN identifier";
}
}
container qinq {
when "../l2-access-type='vpn-common:qinq'";
if-feature "vpn-common:qinq";
description
"QinQ";
leaf s-vlan-id {
type uint32;
description
"S-VLAN Identifier";
}
leaf c-vlan-id {
type uint32;
description
"C-VLAN Identifier";
}
}
container qinany {
if-feature "vpn-common:qinany";
description
"Container for Q in Any";
Barguil, et al. Expires November 1, 2021 [Page 52]
Internet-Draft L2NM April 2021
leaf s-vlan-id {
type uint32;
description
"S-Vlan ID";
}
}
container vxlan {
when "../l2-access-type='vpn-common:vxlan'";
if-feature "vxlan";
description
"QinQ";
leaf vni-id {
type uint32;
description
"VNI Identifier";
}
leaf peer-mode {
type identityref {
base vpn-common:vxlan-peer-mode;
}
description
"specify the vxlan access mode";
}
leaf-list peer-list {
type inet:ip-address;
description
"Peer IP address.";
}
}
}
container phy-interface {
description
"Container of PHY Interface Attributes configurations";
leaf port-number {
type uint32;
description
"Port number";
}
leaf port-speed {
type uint32;
description
"Port speed";
}
leaf mode {
type identityref {
base vpn-common:neg-mode;
}
description
Barguil, et al. Expires November 1, 2021 [Page 53]
Internet-Draft L2NM April 2021
"Negotiation mode";
}
leaf phy-mtu {
type uint32;
description
"PHY MTU";
}
leaf flow-control {
type string;
description
"Flow control";
}
container oam-802.3ah-link {
if-feature "oam-3ah";
description
"Container for oam 802.3 ah link.";
leaf enable {
type boolean;
description
"Indicate whether support oam 802.3 ah link";
}
}
leaf uni-loop-prevention {
type boolean;
description
"If this leaf set to truth that the port automatically
goes down when a physical loopback is detect.";
}
}
container lag-interface {
if-feature "vpn-common:lag-interface";
description
"Container of LAG interface attributes configuration";
list lag-interface {
key "lag-interface-number";
description
"List of LAG interfaces";
leaf lag-interface-number {
type uint32;
description
"LAG interface number";
}
container lacp {
description
"LACP";
leaf lacp-state {
type boolean;
description
Barguil, et al. Expires November 1, 2021 [Page 54]
Internet-Draft L2NM April 2021
"LACP on/off";
}
leaf lacp-mode {
type boolean;
description
"LACP mode";
}
leaf lacp-speed {
type boolean;
description
"LACP speed";
}
leaf mini-link {
type uint32;
description
"The minimum aggregate bandwidth for a LAG";
}
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";
}
Barguil, et al. Expires November 1, 2021 [Page 55]
Internet-Draft L2NM April 2021
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
"Indicate whether support oam 802.3 ah link";
}
}
}
}
leaf flow-control {
type string;
description
"Flow control";
}
leaf lldp {
type boolean;
description
"LLDP";
}
}
}
}
list cvlan-id-to-svc-map {
key "svc-id";
description
"List for cvlan-id to L2VPn Service map configurations";
leaf svc-id {
type leafref {
Barguil, et al. Expires November 1, 2021 [Page 56]
Internet-Draft L2NM April 2021
path "/l2vpn-ntw/vpn-services/vpn-service/vpn-id";
}
description
"VPN Service identifier";
}
list cvlan-id {
key "vid";
description
"List of CVLAN-ID to SVC Map configurations";
leaf vid {
type uint32;
description
"CVLAN ID";
}
}
}
container split-horizon {
description
"Configuration with split horizon enabled";
leaf group-name {
type string;
description
"group-name of the Split Horizon";
}
}
}
container TO-SIMPLFY-diversity-redundancy-TO-SIMPLFY {
description
"placeholder. TO BE FURTHER WORKED OUT.";
container access-diversity {
if-feature "vpn-common:placement-diversity";
description
"Diversity parameters.";
container groups {
description
"Groups the fate sharing group member
is belonging to";
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 fate-sharing-group-size {
Barguil, et al. Expires November 1, 2021 [Page 57]
Internet-Draft L2NM April 2021
type uint16;
description
"Fate sharing group size.";
}
leaf group-color {
type string;
description
"Group color associated with a particular VPN.";
}
leaf ethernet-segment-identifier {
type yang:hex-string {
length "29";
}
description
"10-octet Ethernet Segment Identifier (ESI).";
}
leaf esi-redundancy-mode {
type identityref {
base evpn-redundancy-mode;
}
description
"Indicates the EVPN redundancy mode for
a multihomed CE.";
}
}
}
}
container constraints {
description
"Constraints for placing this site
network access.";
list constraint {
key "constraint-type";
description
"List of constraints.";
leaf constraint-type {
type identityref {
base vpn-common:placement-diversity;
}
description
"Diversity constraint type.";
}
container target {
description
"The constraint will apply against
this list of groups.";
choice target-flavor {
description
Barguil, et al. Expires November 1, 2021 [Page 58]
Internet-Draft L2NM April 2021
"Choice for the group definition.";
case id {
list group {
key "group-id";
description
"List of groups";
leaf group-id {
type string;
description
"The constraint will apply
against this particular
group-id.";
}
}
}
case all-accesses {
leaf all-other-accesses {
type empty;
description
"The constraint will apply
against all other site network
access of this site.";
}
}
case all-groups {
leaf all-other-groups {
type empty;
description
"The constraint will apply
against all other groups the
customer is managing.";
}
}
}
}
}
}
container availability {
description
"Container of availability optional configurations";
leaf access-priority {
type uint32;
description
"Access priority";
}
choice redundancy-mode {
description
"Redundancy mode choice";
Barguil, et al. Expires November 1, 2021 [Page 59]
Internet-Draft L2NM April 2021
case single-active {
description
"Single active case";
leaf single-active {
type boolean;
description
"Single active";
}
}
case all-active {
description
"All active case";
leaf all-active {
type boolean;
description
"All active";
}
}
}
}
container precedence {
description
"Transport netowrk precedence selector
Primary or Secondary tunnel.";
leaf precedence {
type identityref {
base precedence-type;
}
description
"Defining service redundancy in transport
network.";
}
}
}
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 {
Barguil, et al. Expires November 1, 2021 [Page 60]
Internet-Draft L2NM April 2021
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-input-bandwidth {
if-feature "vpn-common:input-bw";
description
"From the PE perspective, the service input
bandwidth of the connection.";
list input-bandwidth {
key "type";
description
"List for input bandwidth";
leaf type {
type identityref {
base vpn-common:bw-type;
}
description
"Bandwidth Type";
}
leaf cos-id {
type uint8;
Barguil, et al. Expires November 1, 2021 [Page 61]
Internet-Draft L2NM April 2021
description
"Identifier of Class of Service
, 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., maixmum frame delivery
allowed. It is equal to or less than sum of cir and
eir.";
}
leaf pbs {
type uint64;
description
"Peak Burst Size. It is measured in bytes per second.";
}
}
Barguil, et al. Expires November 1, 2021 [Page 62]
Internet-Draft L2NM April 2021
}
container svc-output-bandwidth {
if-feature "output-bw";
description
"From the PE perspective, the service output
bandwidth of the connection.";
list output-bandwidth {
key "type";
description
"List for output bandwidth";
leaf type {
type identityref {
base vpn-common:bw-type;
}
description
"Bandwidth Type";
}
leaf cos-id {
type uint8;
description
"Identifier of Class of Service
, 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;
Barguil, et al. Expires November 1, 2021 [Page 63]
Internet-Draft L2NM April 2021
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., maixmum frame delivery
allowed. It is equal to or less than sum of cir and
eir.";
}
leaf pbs {
type uint64;
description
"Peak Burst Size. It is measured in bytes per second.";
}
}
}
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 {
Barguil, et al. Expires November 1, 2021 [Page 64]
Internet-Draft L2NM April 2021
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 {
type yang:mac-address;
description
"Source MAC address.";
}
leaf dst-mac {
type yang:mac-address;
description
"Destination MAC address.";
}
leaf color-type {
type identityref {
base color-type;
}
description
"Color types.";
}
leaf any {
type empty;
description
"Allow all.";
}
}
}
case match-application {
leaf match-application {
type identityref {
base vpn-common:customer-application;
}
description
"Defines the application to match.";
Barguil, et al. Expires November 1, 2021 [Page 65]
Internet-Draft L2NM April 2021
}
}
}
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.";
container access-control-list {
description
"Container for access control List.";
Barguil, et al. Expires November 1, 2021 [Page 66]
Internet-Draft L2NM April 2021
list mac {
key "mac-address";
description
"List for MAC addresses.";
leaf mac-address {
type yang:mac-address;
description
"Specifies a MAC address.";
}
}
}
container mac-loop-prevention {
description
"Container of MAC loop prevention.";
leaf frequency {
type uint32;
description
"Frequency";
}
leaf protection-type {
type identityref {
base loop-prevention-type;
}
description
"Protection type";
}
leaf number-retries {
type uint32;
description
"Number of retries";
}
}
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 {
Barguil, et al. Expires November 1, 2021 [Page 67]
Internet-Draft L2NM April 2021
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 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 {
Barguil, et al. Expires November 1, 2021 [Page 68]
Internet-Draft L2NM April 2021
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>
Figure 11
8. Security Considerations
The YANG module 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 this 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)
Barguil, et al. Expires November 1, 2021 [Page 69]
Internet-Draft L2NM April 2021
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:
o 'vpn-service': An attacker who is able to access network nodes can
undertake various attacks, such as deleting a running L2VPN
service, interrupting all the traffic of a client. In addition,
an attacker may modify the attributes of a running service (e.g.,
QoS, bandwidth), leading to malfunctioning of the service and
therefore to SLA violations. In addition, an attacker could
attempt to create an L2VPN service or adding a new network access.
Such activity can be detected by adequately monitoring and
tracking network configuration changes.
Some of the readable data nodes in this 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:
o 'customer-name' and 'ip-connection': An attacker can retrieve
privacy-related information which can be used to track a customer.
Disclosing such information may be considered as a violation of
the customer-provider trust relationship.
The following summarizes the foreseen risks of using the "ietf-l2vpn-
ntw" module can be classified into:
o Malicious clients attempting to delete or modify VPN services.
o Unauthorized clients attempting to create/modify/delete a VPN
service.
o Unauthorized clients attempting to read VPN service related
information.
9. IANA Considerations
This document requests IANA to register the following URI in the "ns"
subregistry within the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
Barguil, et al. Expires November 1, 2021 [Page 70]
Internet-Draft L2NM April 2021
This document requests IANA to register the following YANG module in
the "YANG Module Names" subregistry [RFC6020] within the "YANG
Parameters" registry:
name: ietf-l2vpn-ntw
namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw
maintained by IANA: N
prefix: l2vpn-ntw
reference: RFC XXXX
10. References
10.1. Normative References
[I-D.ietf-opsawg-vpn-common]
barguil, s., Dios, O., Boucadair, M., and Q. WU, "A Layer
2/3 VPN Common YANG Model", draft-ietf-opsawg-vpn-
common-03 (work in progress), January 2021.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<https://www.rfc-editor.org/info/rfc4761>.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<https://www.rfc-editor.org/info/rfc4762>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo,
"Provisioning, Auto-Discovery, and Signaling in Layer 2
Virtual Private Networks (L2VPNs)", RFC 6074,
DOI 10.17487/RFC6074, January 2011,
<https://www.rfc-editor.org/info/rfc6074>.
Barguil, et al. Expires November 1, 2021 [Page 71]
Internet-Draft L2NM April 2021
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2
Virtual Private Networks Using BGP for Auto-Discovery and
Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012,
<https://www.rfc-editor.org/info/rfc6624>.
[RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N.,
Henderickx, W., and A. Isaac, "Requirements for Ethernet
VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014,
<https://www.rfc-editor.org/info/rfc7209>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
Henderickx, "Provider Backbone Bridging Combined with
Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
September 2015, <https://www.rfc-editor.org/info/rfc7623>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
Rabadan, "Virtual Private Wire Service Support in Ethernet
VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
<https://www.rfc-editor.org/info/rfc8214>.
Barguil, et al. Expires November 1, 2021 [Page 72]
Internet-Draft L2NM April 2021
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG
Data Model for Layer 2 Virtual Private Network (L2VPN)
Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October
2018, <https://www.rfc-editor.org/info/rfc8466>.
10.2. Informative References
[I-D.ietf-teas-enhanced-vpn]
Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
Framework for Enhanced Virtual Private Network (VPN+)
Services", draft-ietf-teas-enhanced-vpn-07 (work in
progress), February 2021.
[I-D.ietf-teas-ietf-network-slices]
Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S.,
Makhijani, K., Contreras, L. M., and J. Tantsura,
"Framework for IETF Network Slices", draft-ietf-teas-ietf-
network-slices-00 (work in progress), April 2021.
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B.
Moore, "Policy Quality of Service (QoS) Information
Model", RFC 3644, DOI 10.17487/RFC3644, November 2003,
<https://www.rfc-editor.org/info/rfc3644>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
Barguil, et al. Expires November 1, 2021 [Page 73]
Internet-Draft L2NM April 2021
[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP
Connectivity Provisioning Profile (CPP)", RFC 7297,
DOI 10.17487/RFC7297, July 2014,
<https://www.rfc-editor.org/info/rfc7297>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
[RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and
L. Geng, "A Framework for Automating Service and Network
Management with YANG", RFC 8969, DOI 10.17487/RFC8969,
January 2021, <https://www.rfc-editor.org/info/rfc8969>.
Appendix A. Examples
To be completed
Acknowledgements
During the discussions of this work, helpful comments, suggestions,
and reviews were received from: Sergio Belotti, Italo Busi, Miguel
Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque Gagliano,
Christian Jacquenet, Kireeti Kompella, Julian Lucek, 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.
Barguil, et al. Expires November 1, 2021 [Page 74]
Internet-Draft L2NM April 2021
Contributors
Victor Lopez
Telefonica
Email: victor.lopezalvarez@telefonica.com
Qin Wu
Huawei
Email: bill.wu@huawei.com
Raul Arco
Nokia
Email: raul.arco@nokia.com
Authors' Addresses
Samier Barguil (editor)
Telefonica
Madrid
ES
Email: samier.barguilgiraldo.ext@telefonica.com
Oscar Gonzalez de Dios (editor)
Telefonica
Madrid
ES
Email: oscar.gonzalezdedios@telefonica.com
Mohamed Boucadair (editor)
Orange
France
Email: mohamed.boucadair@orange.com
Luis Angel Munoz
Vodafone
ES
Email: luis-angel.munoz@vodafone.com
Barguil, et al. Expires November 1, 2021 [Page 75]