rfc9291.original   rfc9291.txt 
OPSAWG M. Boucadair, Ed. Internet Engineering Task Force (IETF) M. Boucadair, Ed.
Internet-Draft Orange Request for Comments: 9291 Orange
Intended status: Standards Track O. Gonzalez de Dios, Ed. Category: Standards Track O. Gonzalez de Dios, Ed.
Expires: 4 December 2022 S. Barguil ISSN: 2070-1721 S. Barguil
Telefonica Telefonica
L. Munoz L. Munoz
Vodafone Vodafone
2 June 2022 September 2022
A YANG Network Data Model for Layer 2 VPNs A YANG Network Data Model for Layer 2 VPNs
draft-ietf-opsawg-l2nm-19
Abstract Abstract
This document defines an L2VPN Network YANG Model (L2NM) which can be This document defines an L2VPN Network Model (L2NM) that can be used
used to manage the provisioning of Layer 2 Virtual Private Network to manage the provisioning of Layer 2 Virtual Private Network (L2VPN)
services within a network (e.g., service provider network). The L2NM services within a network (e.g., a service provider network). The
complements the Layer 2 Service Model (L2SM) by providing a network- L2NM complements the L2VPN Service Model (L2SM) by providing a
centric view of the service that is internal to a service provider. network-centric view of the service that is internal to a service
The L2NM is particularly meant to be used by a network controller to provider. The L2NM is particularly meant to be used by a network
derive the configuration information that will be sent to relevant controller to derive the configuration information that will be sent
network devices. to relevant network devices.
Also, this document defines a YANG module to manage Ethernet segments Also, this document defines a YANG module to manage Ethernet segments
and the initial versions of two IANA-maintained modules that include and the initial versions of two IANA-maintained modules that include
a set of identities of BGP Layer 2 encapsulation types and pseudowire a set of identities of BGP Layer 2 encapsulation types and pseudowire
types. types.
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:
* "This version of this YANG module is part of RFC XXXX;"
* "RFC XXXX: A YANG Network Data Model for Layer 2 VPNs";
* reference: RFC XXXX
Also, please update the "revision" date of the YANG modules.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 4 December 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9291.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . . 6 3. Acronyms and Abbreviations
4. Reference Architecture . . . . . . . . . . . . . . . . . . . 6 4. Reference Architecture
5. Relationship to Other YANG Data Models . . . . . . . . . . . 11 5. Relationship to Other YANG Data Models
6. Description of the Ethernet Segment YANG Module . . . . . . . 12 6. Description of the Ethernet Segment YANG Module
7. Description of the L2NM YANG Module . . . . . . . . . . . . . 15 7. Description of the L2NM YANG Module
7.1. Overall Structure of the Module . . . . . . . . . . . . . 15 7.1. Overall Structure of the Module
7.2. VPN Profiles . . . . . . . . . . . . . . . . . . . . . . 16 7.2. VPN Profiles
7.3. VPN Services . . . . . . . . . . . . . . . . . . . . . . 17 7.3. VPN Services
7.4. Global Parameters Profiles . . . . . . . . . . . . . . . 21 7.4. Global Parameters Profiles
7.5. VPN Nodes . . . . . . . . . . . . . . . . . . . . . . . . 25 7.5. VPN Nodes
7.5.1. BGP Auto-Discovery . . . . . . . . . . . . . . . . . 28 7.5.1. BGP Auto-Discovery
7.5.2. Signaling Options . . . . . . . . . . . . . . . . . . 29 7.5.2. Signaling Options
7.5.2.1. BGP . . . . . . . . . . . . . . . . . . . . . . . 31 7.5.2.1. BGP
7.5.2.2. LDP . . . . . . . . . . . . . . . . . . . . . . . 33 7.5.2.2. LDP
7.5.2.3. L2TP . . . . . . . . . . . . . . . . . . . . . . 34 7.5.2.3. L2TP
7.6. VPN Network Accesses . . . . . . . . . . . . . . . . . . 34 7.6. VPN Network Accesses
7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 36 7.6.1. Connection
7.6.2. EVPN-VPWS Service Instance . . . . . . . . . . . . . 39 7.6.2. EVPN-VPWS Service Instance
7.6.3. Ethernet OAM . . . . . . . . . . . . . . . . . . . . 41 7.6.3. Ethernet OAM
7.6.4. Services . . . . . . . . . . . . . . . . . . . . . . 42 7.6.4. Services
8. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 48 8. YANG Modules
8.1. IANA-Maintained Module for BGP Layer 2 Encapsulation 8.1. IANA-Maintained Module for BGP Layer 2 Encapsulation Types
Types . . . . . . . . . . . . . . . . . . . . . . . . . . 48 8.2. IANA-Maintained Module for Pseudowire Types
8.2. IANA-Maintained Module for Pseudowire Types . . . . . . . 54 8.3. Ethernet Segments
8.3. Ethernet Segments . . . . . . . . . . . . . . . . . . . . 61 8.4. L2NM
8.4. L2NM . . . . . . . . . . . . . . . . . . . . . . . . . . 69 9. Security Considerations
9. Security Considerations . . . . . . . . . . . . . . . . . . . 123 10. IANA Considerations
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 124 10.1. Registering YANG Modules
10.1. Registering YANG Modules . . . . . . . . . . . . . . . . 124 10.2. BGP Layer 2 Encapsulation Types
10.2. BGP Layer 2 Encapsulation Types . . . . . . . . . . . . 126 10.3. Pseudowire Types
10.3. Pseudowire Types . . . . . . . . . . . . . . . . . . . . 126 11. References
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 127 11.1. Normative References
11.1. Normative References . . . . . . . . . . . . . . . . . . 127 11.2. Informative References
11.2. Informative References . . . . . . . . . . . . . . . . . 130 Appendix A. Examples
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 136 A.1. BGP-Based VPLS
A.1. BGP-based VPLS . . . . . . . . . . . . . . . . . . . . . 136 A.2. BGP-Based VPWS with LDP Signaling
A.2. BGP-based VPWS with LDP Signaling . . . . . . . . . . . . 142 A.3. LDP-Based VPLS
A.3. LDP-based VPLS . . . . . . . . . . . . . . . . . . . . . 145 A.4. VPWS-EVPN Service Instance
A.4. VPWS-EVPN Service Instance . . . . . . . . . . . . . . . 149 A.5. Automatic ESI Assignment
A.5. Automatic ESI Assignment . . . . . . . . . . . . . . . . 155 A.6. VPN Network Access Precedence
A.6. VPN Network Access Precedence . . . . . . . . . . . . . . 158 Acknowledgements
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 161 Contributors
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 162
1. Introduction 1. Introduction
[RFC8466] defines an L2VPN Service Model (L2SM) YANG data model that [RFC8466] defines an L2VPN Service Model (L2SM) YANG data model that
can be used between customers and service providers for ordering can be used between customers and service providers for ordering
Layer 2 Virtual Private Network (L2VPN) services. This document Layer 2 Virtual Private Network (L2VPN) services. This document
complements the L2SM by creating a network-centric view of the complements the L2SM by creating a network-centric view of the
service: the L2VPN Network Model (L2NM). service: the L2VPN Network Model (L2NM).
Also, this document defines the initial versions of two IANA- Also, this document defines the initial versions of two IANA-
maintained modules that define a set of identities of BGP Layer 2 maintained modules that define a set of identities of BGP Layer 2
encapsulation types (Section 8.1) and pseudowire types (Section 8.2). encapsulation types (Section 8.1) and pseudowire types (Section 8.2).
These types are used in the L2NM to identify a Layer 2 encapsulation These types are used in the L2NM to identify a Layer 2 encapsulation
type as a function of the signalling option used to deliver an L2VPN type as a function of the signaling option used to deliver an L2VPN
service. Relying upon these IANA-maintained modules is meant to service. Relying upon these IANA-maintained modules is meant to
provide more flexibility in handling new types rather than being provide more flexibility in handling new types rather than being
limited by a set of identities defined in the L2NM itself. limited by a set of identities defined in the L2NM itself.
Section 8.3 defines another YANG module to manage Ethernet Segments Section 8.3 defines another YANG module to manage Ethernet Segments
(ESes) that are required for instantiating Ethernet VPNs (EVPNs). (ESes) that are required for instantiating Ethernet VPNs (EVPNs).
References to Ethernet segments that are created using the module in References to Ethernet segments that are created using the module in
Section 8.3 can be included in the L2NM for EVPNs. Section 8.3 can be included in the L2NM for EVPNs.
The L2NM (Section 8.4) can be exposed, for example, by a network The L2NM (Section 8.4) can be exposed, for example, by a network
controller to a service controller within the service provider's controller to a service controller within the service provider's
network. In particular, the model can be used in the communication network. In particular, the model can be used in the communication
interface between the entity that interacts directly with the interface between the entity that interacts directly with the
customer (i.e., the service orchestrator) and the entity in charge of customer (i.e., the service orchestrator) and the entity in charge of
network orchestration and control (a.k.a., network controller/ network orchestration and control (a.k.a., network controller/
orchestrator) by allowing for more network-centric information to be orchestrator) by allowing for more network-centric information to be
included. included.
The L2NM supports capabilities, such as exposing operational The L2NM supports capabilities such as exposing operational
parameters, transport protocols selection, and precedence. It can parameters, transport protocols selection, and precedence. It can
also serve as a multi-domain orchestration interface. also serve as a multi-domain orchestration interface.
The L2NM is scoped for a variety of Layer 2 Virtual Private Networks, The L2NM is scoped for a variety of Layer 2 Virtual Private Networks
such as: such as:
* Virtual Private LAN Service (VPLS) [RFC4761][RFC4762] * Virtual Private LAN Service (VPLS) [RFC4761] [RFC4762]
* Virtual Private Wire Service (VPWS) (Section 3.1.1 of [RFC4664]) * Virtual Private Wire Service (VPWS) (Section 3.1.1 of [RFC4664])
* Various flavors of EVPNs: * Various flavors of EVPNs:
- VPWS EVPN [RFC8214], - VPWS EVPN [RFC8214],
- Provider Backbone Bridging Ethernet VPNs (PBB EVPNs) [RFC7623], - Provider Backbone Bridging Combined with Ethernet VPNs (PBB-
EVPNs) [RFC7623],
- EVPN over MPLS [RFC7432], and - EVPN over MPLS [RFC7432], and
- EVPN over Virtual eXtensible Local Area Network (VXLAN) - EVPN over Virtual Extensible LAN (VXLAN) [RFC8365].
[RFC8365].
The L2NM is designed to easily support future Layer 2 VPN flavors and The L2NM is designed to easily support future Layer 2 VPN flavors and
procedures (e.g., advanced configuration such as pseudowires procedures (e.g., advanced configuration such as pseudowires
resilience or Multi-Segment pseudowires [RFC7267]). A set of resilience or multi-segment pseudowires [RFC7267]). A set of
examples to illustrate the use of the L2NM are provided in examples to illustrate the use of the L2NM are provided in
Appendix A. Appendix A.
This document uses the common Virtual Private Network (VPN) YANG This document uses the common Virtual Private Network (VPN) YANG
module defined in [RFC9181]. module defined in [RFC9181].
The YANG data models in this document conforms to the Network The YANG data models in this document conform to the Network
Management Datastore Architecture (NMDA) defined in [RFC8342]. Management Datastore Architecture (NMDA) defined in [RFC8342].
2. Terminology 2. Terminology
This document assumes that the reader is familiar with [RFC6241], This document assumes that the reader is familiar with [RFC6241],
[RFC7950], [RFC8466], [RFC4026], and [RFC8309]. This document uses [RFC7950], [RFC8466], [RFC4026], and [RFC8309]. This document uses
terminology from those documents. terminology from those documents.
This document uses the term "network model" as defined in Section 2.1 This document uses the term "network model" as defined in Section 2.1
of [RFC8969]. of [RFC8969].
The meanings of the symbols in YANG tree diagrams is defined in The meanings of the symbols in the YANG tree diagrams are defined in
[RFC8340]. [RFC8340].
This document makes use of the following terms: This document makes use of the following terms:
Ethernet segment (ES): Refers to the set of the Ethernet links that Ethernet Segment (ES): Refers to the set of Ethernet links that are
are used by a customer site (device or network) to connect to one used by a customer site (device or network) to connect to one or
or more Provider Edges (PEs). more Provider Edges (PEs).
Layer 2 VPN Service Model (L2SM): Describes the service L2VPN Service Model (L2SM): Describes the service characterization
characterization of an L2VPN that interconnects a set of sites of an L2VPN that interconnects a set of sites from the customer's
from the customer's perspective. The customer service model does perspective. The customer service model does not provide details
not provide details on the service provider network. An L2VPN on the service provider network. An L2VPN customer service model
customer service model is defined in [RFC8466]. is defined in [RFC8466].
Layer 2 VPN Network Model (L2NM): Refers to the YANG data model that L2VPN Network Model (L2NM): Refers to the YANG data model that
describes an L2VPN service with a network-centric view. It describes an L2VPN service with a network-centric view. It
contains information on the service provider network and might contains information on the service provider network and might
include allocated resources. Network controllers can use it to include allocated resources. Network controllers can use it to
manage the Layer 2 VPN service configuration in the service manage the Layer 2 VPN service configuration in the service
provider's network. The corresponding YANG module can be used by provider's network. The corresponding YANG module can be used by
a service orchestrator to request a VPN service to a network a service orchestrator to request a VPN service to a network
controller or to expose the list of active L2VPN services. The controller or to expose the list of active L2VPN services. The
L2NM can also be used to retrieve a set of L2VPN-related state L2NM can also be used to retrieve a set of L2VPN-related state
information (including OAM). information (including Operations, Administration, and Maintenance
(OAM)).
MAC-VRF: Refers to a Virtual Routing and Forwarding (VRF) table for MAC-VRF: Refers to a Virtual Routing and Forwarding (VRF) table for
Media Access Control (MAC) addresses on a PE. Media Access Control (MAC) addresses on a PE.
Network controller: Denotes a functional entity responsible for the Network controller: Denotes a functional entity responsible for the
management of the service provider network. management of the service provider network.
Service orchestrator: Refers to a functional entity that interacts Service orchestrator: Refers to a functional entity that interacts
with the customer of an L2VPN relying upon, e.g., the L2SM. The with the customer of an L2VPN relying upon, e.g., the L2SM. The
service orchestrator is responsible for the Customer Edge - to service orchestrator is responsible for the Customer Edge to
Provider Edge (CE-PE) attachment circuits, the PE selection, and Provider Edge (CE-PE) attachment circuits, the PE selection, and
requesting the activation of the L2VPN service to a network requesting the activation of the L2VPN service to a network
controller. controller.
Service provider network: Is a network able to provide L2VPN-related Service provider network: A network that is able to provide L2VPN-
services. related services.
VPN node: Is an abstraction that represents a set of policies VPN node: An abstraction that represents a set of policies applied
applied on a PE and belonging to a single VPN service. A VPN on a PE and belongs to a single VPN service. A VPN service
service involves one or more VPN nodes. The VPN node will involves one or more VPN nodes. The VPN node will identify the
identify the service providers' node on which the VPN is deployed. service providers' node on which the VPN is deployed.
VPN network access: Is an abstraction that represents the network VPN network access: An abstraction that represents the network
interfaces that are associated with a given VPN node. Traffic interfaces that are associated with a given VPN node. Traffic
coming from the VPN network access belongs to the VPN. The coming from the VPN network access belongs to the VPN. The
attachment circuits (bearers) between Customer Edges (CEs) and attachment circuits (bearers) between CEs and PEs are terminated
Provider Edges (PEs) are terminated in the VPN network access. in the VPN network access.
VPN service provider: Is a service provider that offers L2VPN- VPN service provider: A service provider that offers L2VPN-related
related services. services.
3. Acronyms and Abbreviations 3. Acronyms and Abbreviations
The following acronyms and abbreviations are used in this document: The following acronyms and abbreviations are used in this document:
ACL Access Control List ACL Access Control List
BGP Border Gateway Protocol BGP Border Gateway Protocol
BUM Broadcast, unknown unicast, or multicast BUM Broadcast, Unknown Unicast, or Multicast
CE Customer Edge CE Customer Edge
ES Ethernet Segment ES Ethernet Segment
ESI Ethernet Segment Identifier ESI Ethernet Segment Identifier
EVPN Ethernet VPN EVPN Ethernet VPN
L2VPN Layer 2 Virtual Private Network L2VPN Layer 2 Virtual Private Network
L2SM L2VPN Service Model L2SM L2VPN Service Model
L2NM L2VPN Network Model L2NM L2VPN Network Model
MAC Media Access Control MAC Media Access Control
PBB Provider Backbone Bridging PBB Provider Backbone Bridging
PCP Priority Code Point PCP Priority Code Point
skipping to change at page 7, line 6 skipping to change at line 270
[RFC8466] and decomposes the box marked "orchestration" in that [RFC8466] and decomposes the box marked "orchestration" in that
figure into three separate functional components called "Service figure into three separate functional components called "Service
Orchestration", "Network Orchestration", and "Domain Orchestration". Orchestration", "Network Orchestration", and "Domain Orchestration".
Similar to Section 3 of [RFC8466], CE to PE attachment is achieved Similar to Section 3 of [RFC8466], CE to PE attachment is achieved
through a bearer with a Layer 2 connection on top. The bearer refers through a bearer with a Layer 2 connection on top. The bearer refers
to properties of the attachment that are below Layer 2, while the to properties of the attachment that are below Layer 2, while the
connection refers to Layer 2 protocol-oriented properties. connection refers to Layer 2 protocol-oriented properties.
The reader may refer to [RFC8309] for the distinction between the The reader may refer to [RFC8309] for the distinction between the
"Customer Service Model", the "Service Delivery Model", the "Network "Customer Service Model", "Service Delivery Model", "Network
Configuration Model", and the "Device Configuration Model". The Configuration Model", and "Device Configuration Model". The "Domain
"Domain Orchestration" and "Config Manager" roles may be performed by Orchestration" and "Config Manager" roles may be performed by "SDN
"SDN Controllers". Controllers".
+---------------+ +---------------+
| Customer | | Customer |
+-------+-------+ +-------+-------+
Customer Service Model | Customer Service Model |
e.g., l2vpn-svc | e.g., l2vpn-svc |
+-------+-------+ +-------+-------+
| Service | | Service |
| Orchestration | | Orchestration |
+-------+-------+ +-------+-------+
skipping to change at page 9, line 11 skipping to change at line 327
CLI: Command-Line Interface CLI: Command-Line Interface
Figure 1: L2SM and L2NM Interaction Figure 1: L2SM and L2NM Interaction
The customer may use various means to request a service that may The customer may use various means to request a service that may
trigger the instantiation of an L2NM. The customer may use the L2SM trigger the instantiation of an L2NM. The customer may use the L2SM
or may rely upon more abstract models to request a service that or may rely upon more abstract models to request a service that
relies upon an L2VPN service. For example, the customer may supply relies upon an L2VPN service. For example, the customer may supply
an IP Connectivity Provisioning Profile (CPP) that characterizes the an IP Connectivity Provisioning Profile (CPP) that characterizes the
requested service [RFC7297], an enhanced VPN (VPN+) service requested service [RFC7297], an enhanced VPN (VPN+) service
[I-D.ietf-teas-enhanced-vpn], or an IETF network slice service [VPN+-FRAMEWORK], or an IETF network slice service [IETF-NET-SLICES].
[I-D.ietf-teas-ietf-network-slices].
Note also that both the L2SM and the L2NM may be used in the context Note also that both the L2SM and L2NM may be used in the context of
of the Abstraction and Control of TE Networks (ACTN) framework the Abstraction and Control of TE Networks (ACTN) framework
[RFC8453]. Figure 2 shows the Customer Network Controller (CNC), the [RFC8453]. Figure 2 shows the Customer Network Controller (CNC), the
Multi-Domain Service Coordinator (MDSC), and the Provisioning Network Multi-Domain Service Coordinator (MDSC), and the Provisioning Network
Controller (PNC). Controller (PNC).
+----------------------------------+ +----------------------------------+
| Customer | | Customer |
| +-----------------------------+ | | +-----------------------------+ |
| | CNC | | | | CNC | |
| +-----------------------------+ | | +-----------------------------+ |
+----+-----------------------+-----+ +----+-----------------------+-----+
skipping to change at page 11, line 9 skipping to change at line 381
+----+---+ +----+---+ +----+---+ +----+---+
| Device | | Device | | Device | | Device |
+--------+ +--------+ +--------+ +--------+
Figure 2: L2SM and L2NM in the Context of ACTN Figure 2: L2SM and L2NM in the Context of ACTN
5. Relationship to Other YANG Data Models 5. Relationship to Other YANG Data Models
The "ietf-vpn-common" module [RFC9181] includes a set of identities, The "ietf-vpn-common" module [RFC9181] includes a set of identities,
types, and groupings that are meant to be reused by VPN-related YANG 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 modules independently of the layer (e.g., Layer 2 or Layer 3) and the
type of the module (e.g., network model, service model) including type of the module (e.g., network model or service model) including
future revisions of existing models (e.g., [RFC8466]). The L2NM future revisions of existing models (e.g., [RFC8466]). The L2NM
reuses these common types and groupings. reuses these common types and groupings.
Also, the L2NM uses the IANA-maintained modules "iana-bgp-l2-encaps" Also, the L2NM uses the IANA-maintained modules "iana-bgp-l2-encaps"
(Section 8.1) and "iana-pseudowire-types" (Section 8.2) to identify (Section 8.1) and "iana-pseudowire-types" (Section 8.2) to identify
Layer 2 encapsulation and pseudowire types. More details are Layer 2 encapsulation and pseudowire types. More details are
provided in Sections 7.5.2.1 and 7.5.2.3. provided in Sections 7.5.2.1 and 7.5.2.3.
For the particular case of EVPN, the L2NM includes a name that refers For the particular case of EVPN, the L2NM includes a name that refers
to an Ethernet segment that is created using the "ietf-ethernet- to an Ethernet segment that is created using the "ietf-ethernet-
skipping to change at page 11, line 34 skipping to change at line 406
As discussed in Section 4, the L2NM is used to manage L2VPN services As discussed in Section 4, the L2NM is used to manage L2VPN services
within a service provider network. The module provides a network within a service provider network. The module provides a network
view of the L2VPN service. Such a view is only visible to the view of the L2VPN service. Such a view is only visible to the
service provider and is not exposed outside (to customers, for service provider and is not exposed outside (to customers, for
example). The following discusses how the L2NM interfaces with other example). The following discusses how the L2NM interfaces with other
YANG modules: YANG modules:
L2SM: The L2NM is not a customer service model. L2SM: The L2NM is not a customer service model.
The internal view of the service (i.e., the L2NM) may be mapped to The internal view of the service (i.e., the L2NM) may be mapped to
an external view which is visible to customers: L2VPN Service an external view that is visible to customers: L2VPN Service Model
Model (L2SM) [RFC8466]. (L2SM) [RFC8466].
The L2NM can be fed with inputs that are requested by customers, The L2NM can be fed with inputs that are requested by customers
typically, relying upon an L2SM template. Concretely, some parts and that typically rely on an L2SM template. Concretely, some
of the L2SM module can be directly mapped into the L2NM while parts of the L2SM module can be directly mapped into the L2NM
other parts are generated as a function of the requested service while other parts are generated as a function of the requested
and local guidelines. Finally, there are parts local to the service and local guidelines. Finally, there are parts local to
service provider and do not map directly to the L2SM. the service provider, and they do not map directly to the L2SM.
Note that using the L2NM within a service provider does not Note that using the L2NM within a service provider does not
assume, nor does it preclude, exposing the VPN service via the assume, nor does it preclude, exposing the VPN service via the
L2SM. This is deployment specific. Nevertheless, the design of L2SM. This is deployment specific. Nevertheless, the design of
L2NM tries to align as much as possible with the features L2NM tries to align as much as possible with the features
supported by the L2SM to ease the grafting of both the L2NM and supported by the L2SM to ease the grafting of both the L2NM and
the L2SM for the sake of highly automated VPN service provisioning the L2SM for the sake of highly automated VPN service provisioning
and delivery. and delivery.
Network Topology Modules: An L2VPN involves nodes that are part of a Network Topology Modules: An L2VPN involves nodes that are part of a
topology managed by the service provider network. Such a topology topology managed by the service provider network. Such a topology
can be represented using the network topology module in [RFC8345] can be represented using the network topology module in [RFC8345]
or its extension, such as a network YANG module for Service or its extension, such as a network YANG module for Service
Attachment Points (SAPs) [I-D.ietf-opsawg-sap]. Attachment Points (SAPs) [YANG-SAPS].
Device Modules: The L2NM is not a device model. Device Modules: The L2NM is not a device model.
Once a global VPN service is captured by means of the L2NM, the Once a global VPN service is captured by means of the L2NM, the
actual activation and provisioning of the VPN service will involve actual activation and provisioning of the VPN service will involve
a variety of device modules to tweak the required functions for a variety of device modules to tweak the required functions for
the delivery of the service. These functions are supported by the the delivery of the service. These functions are supported by the
VPN nodes and can be managed using device YANG modules. A non- VPN nodes and can be managed using device YANG modules. A non-
comprehensive list of such device YANG modules is provided below: comprehensive list of such device YANG modules is provided below:
* Interfaces [RFC8343]. * Interfaces [RFC8343]
* BGP [I-D.ietf-idr-bgp-model]. * BGP [BGP-YANG-MODEL]
* MPLS [RFC8960]. * MPLS [RFC8960]
* Access Control Lists (ACLs) [RFC8519]. * Access Control Lists (ACLs) [RFC8519]
How the L2NM is used to derive device-specific actions is How the L2NM is used to derive device-specific actions is
implementation specific. implementation specific.
6. Description of the Ethernet Segment YANG Module 6. Description of the Ethernet Segment YANG Module
The 'ietf-ethernet-segment' module (Figure 3) is used to manage a set The 'ietf-ethernet-segment' module (Figure 3) is used to manage a set
of Ethernet segments in the context of an EVPN service. of Ethernet segments in the context of an EVPN service.
module: ietf-ethernet-segment module: ietf-ethernet-segment
+--rw ethernet-segments +--rw ethernet-segments
+--rw ethernet-segment* [name] +--rw ethernet-segment* [name]
+--rw name string +--rw name string
+--rw esi-type? identityref +--rw esi-type? identityref
+--rw (esi-choice)? +--rw (esi-choice)?
| +--:(directly-assigned) | +--:(directly-assigned)
| | +--rw ethernet-segment-identifier? yang:hex-string | | +--rw ethernet-segment-identifier? yang:hex-string
| +--:(auto-assigned) | +--:(auto-assigned)
| +--rw esi-auto | +--rw esi-auto
| +--rw (auto-mode)? | +--rw (auto-mode)?
| | +--:(from-pool) | | +--:(from-pool)
| | | +--rw esi-pool-name? string | | | +--rw esi-pool-name? string
| | +--:(full-auto) | | +--:(full-auto)
| | +--rw auto? empty | | +--rw auto? empty
| +--ro auto-ethernet-segment-identifier? | +--ro auto-ethernet-segment-identifier?
| yang:hex-string | yang:hex-string
+--rw esi-redundancy-mode? identityref +--rw esi-redundancy-mode? identityref
+--rw df-election +--rw df-election
| +--rw df-election-method? identityref | +--rw df-election-method? identityref
| +--rw revertive? boolean | +--rw revertive? boolean
| +--rw election-wait-time? uint32 | +--rw election-wait-time? uint32
+--rw split-horizon-filtering? boolean +--rw split-horizon-filtering? boolean
+--rw pbb +--rw pbb
| +--rw backbone-src-mac? yang:mac-address | +--rw backbone-src-mac? yang:mac-address
+--rw member* [ne-id interface-id] +--rw member* [ne-id interface-id]
+--rw ne-id string +--rw ne-id string
+--rw interface-id string +--rw interface-id string
Figure 3: Ethernet Segments Tree Structure Figure 3: Ethernet Segments Tree Structure
The descriptions of the data nodes depicted in Figure 3 are as The descriptions of the data nodes depicted in Figure 3 are as
follows: follows:
'name': Sets a name to uniquely identify an ES within a service 'name': Sets a name to uniquely identify an ES within a service
provider network. In order to ease referencing ESes by their name provider network. In order to ease referencing ESes by their name
in other modules, "es-ref" typedef is defined. in other modules, "es-ref" typedef is defined.
skipping to change at page 14, line 39 skipping to change at line 537
segment-identifier'. segment-identifier'.
'esi-redundancy-mode': Specifies the EVPN redundancy mode for a 'esi-redundancy-mode': Specifies the EVPN redundancy mode for a
given ES. The following modes are supported: Single-Active given ES. The following modes are supported: Single-Active
(Section 14.1.1 of [RFC7432]) or All-Active (Section 14.1.2 of (Section 14.1.1 of [RFC7432]) or All-Active (Section 14.1.2 of
[RFC7432]). [RFC7432]).
'df-election': Specifies a set of parameters related to the 'df-election': Specifies a set of parameters related to the
Designated Forwarder (DF) election (Section 8.5 of [RFC7432]). Designated Forwarder (DF) election (Section 8.5 of [RFC7432]).
For example, this data node can be used to indicate an election For example, this data node can be used to indicate an election
method (e.g., [RFC8584] or [I-D.ietf-bess-evpn-pref-df]). If no method (e.g., [RFC8584] or [EVPN-PERF-DF]). If no election method
election method is indicated, the default method defined in is indicated, the default method defined in Section 8.5 of
Section 8.5 of [RFC7432] is used. [RFC7432] is used.
As discussed in Section 1.3.2 of [RFC8584], the default behavior As discussed in Section 1.3.2 of [RFC8584], the default behavior
is to trigger the DF election procedure when a DF fails (e.g., is to trigger the DF election procedure when a DF fails (e.g.,
link failure). The former DF will take over when it is available link failure). The former DF will take over when it is available
again. Such a mode is called revertive. The behavior can be again. Such a mode is called 'revertive'. The behavior can be
overridden by setting the 'revertive' leaf to 'false'. overridden by setting the 'revertive' leaf to 'false'.
Also, this data node can be used to configure a DF Wait timer Also, this data node can be used to configure a DF Wait timer
('election-wait-time') (Section 2.1 of [RFC8584]). ('election-wait-time') (Section 2.1 of [RFC8584]).
'split-horizon-filtering': Controls the activation of the split- 'split-horizon-filtering': Controls the activation of the split-
horizon filtering for an ES (Section 8.3 of [RFC7432]). horizon filtering for an ES (Section 8.3 of [RFC7432]).
'pbb': Indicates data nodes that are specific to PBB [IEEE-802-1ah]: 'pbb': Indicates data nodes that are specific to PBB [IEEE-802-1ah]:
'backbone-src-mac': Associates a Provider Backbone MAC (B-MAC) 'backbone-src-mac': Associates a Provider Backbone MAC (B-MAC)
address with an ES. This is particularly useful for All-Active address with an ES. This is particularly useful for All-Active
multihomed ESes (Section 9.1 of [RFC7623]). multihomed ESes (Section 9.1 of [RFC7623]).
'member': Lists the members of an ES in a service provider network. 'member': Lists the members of an ES in a service provider network.
7. Description of the L2NM YANG Module 7. Description of the L2NM YANG Module
The L2NM ('ietf-l2vpn-ntw', Section 8.4) is used to manage L2VPNs The L2NM ('ietf-l2vpn-ntw'; see Section 8.4) is used to manage L2VPNs
within a service provider network. In particular, the 'ietf-l2vpn- within a service provider network. In particular, the 'ietf-l2vpn-
ntw' module can be used to create, modify, delete and retrieve L2VPN ntw' module can be used to create, modify, delete, and retrieve L2VPN
services in a network controller. The module is designed to minimize services in a network controller. The module is designed to minimize
the amount of customer-related information. the amount of customer-related information.
The full tree diagram of the module can be generated using the The full tree diagram of the module can be generated using the
"pyang" tool [PYANG]. That tree is not included here because it is "pyang" tool [PYANG]. That tree is not included here because it is
too long (Section 3.3 of [RFC8340]). Instead, subtrees are provided too long (Section 3.3 of [RFC8340]). Instead, subtrees are provided
for the reader's convenience. for the reader's convenience.
Note that the following subsections introduce some data nodes that Note that the following subsections introduce some data nodes that
enclose textual descriptions (e.g., VPN service (Section 7.3), VPN enclose textual descriptions (e.g., VPN service (Section 7.3), VPN
skipping to change at page 16, line 5 skipping to change at line 597
The 'vpn-profiles' container is used by the provider to define and The 'vpn-profiles' container is used by the provider to define and
maintain a set of common VPN profiles that apply to VPN services maintain a set of common VPN profiles that apply to VPN services
(Section 7.2). (Section 7.2).
The 'vpn-services' container maintains the set of L2VPN services The 'vpn-services' container maintains the set of L2VPN services
managed in the service provider network. The module allows creating managed in the service provider network. The module allows creating
a new L2VPN service by adding a new instance of 'vpn-service'. The a new L2VPN service by adding a new instance of 'vpn-service'. The
'vpn-service' is the data structure that abstracts the VPN service 'vpn-service' is the data structure that abstracts the VPN service
(Section 7.3). (Section 7.3).
module: ietf-l2vpn-ntw module: ietf-l2vpn-ntw
+--rw l2vpn-ntw +--rw l2vpn-ntw
+--rw vpn-profiles +--rw vpn-profiles
| ... | ...
+--rw vpn-services +--rw vpn-services
+--rw vpn-service* [vpn-id] +--rw vpn-service* [vpn-id]
... ...
+--rw vpn-nodes +--rw vpn-nodes
+--rw vpn-node* [vpn-node-id] +--rw vpn-node* [vpn-node-id]
... ...
+--rw vpn-network-accesses +--rw vpn-network-accesses
+--rw vpn-network-access* [id] +--rw vpn-network-access* [id]
... ...
Figure 4: Overall L2NM Tree Structure Figure 4: Overall L2NM Tree Structure
7.2. VPN Profiles 7.2. VPN Profiles
The 'vpn-profiles' container (Figure 5) is used by a VPN service The 'vpn-profiles' container (Figure 5) is used by a VPN service
provider to define and maintain a set of VPN profiles [RFC9181] that provider to define and maintain a set of VPN profiles [RFC9181] that
apply to one or several VPN services. apply to one or several VPN services.
+--rw l2vpn-ntw +--rw l2vpn-ntw
+--rw vpn-profiles +--rw vpn-profiles
| +--rw valid-provider-identifiers | +--rw valid-provider-identifiers
| +--rw external-connectivity-identifier* [id] | +--rw external-connectivity-identifier* [id]
| | {external-connectivity}? | | {external-connectivity}?
| | +--rw id string | | +--rw id string
| +--rw encryption-profile-identifier* [id] | +--rw encryption-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw qos-profile-identifier* [id] | +--rw qos-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw bfd-profile-identifier* [id] | +--rw bfd-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw forwarding-profile-identifier* [id] | +--rw forwarding-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw routing-profile-identifier* [id] | +--rw routing-profile-identifier* [id]
| +--rw id string | +--rw id string
+--rw vpn-services +--rw vpn-services
... ...
Figure 5: VPN Profiles Subtree Structure Figure 5: VPN Profiles Subtree Structure
The exact definition of these profiles is local to each VPN service The exact definition of these profiles is local to each VPN service
provider. The model only includes an identifier for these profiles provider. The model only includes an identifier for these profiles
in order to ease identifying and binding local policies when building in order to ease identifying and binding local policies when building
a VPN service. As shown in Figure 5, the following identifiers can a VPN service. As shown in Figure 5, the following identifiers can
be included: be included:
'external-connectivity-identifier': This identifier refers to a 'external-connectivity-identifier': This identifier refers to a
profile that defines the external connectivity provided to a VPN profile that defines the external connectivity provided to a VPN
service (or a subset of VPN sites). External connectivity may be service (or a subset of VPN sites). External connectivity may be
access to the Internet or restricted connectivity, such as access access to the Internet or restricted connectivity such as access
to a public/private cloud. to a public/private cloud.
'encryption-profile-identifier': An encryption profile refers to a 'encryption-profile-identifier': An encryption profile refers to a
set of policies related to the encryption schemes and setup that set of policies related to the encryption schemes and setup that
can be applied when building and offering a VPN service. can be applied when building and offering a VPN service.
'qos-profile-identifier': A Quality of Service (QoS) profile refers 'qos-profile-identifier': A Quality of Service (QoS) profile refers
to as set of policies, such as classification, marking, and to a set of policies such as classification, marking, and actions
actions (e.g., [RFC3644]). (e.g., [RFC3644]).
'bfd-profile-identifier': A Bidirectional Forwarding Detection (BFD) 'bfd-profile-identifier': A Bidirectional Forwarding Detection (BFD)
profile refers to a set of BFD policies [RFC5880] that can be profile refers to a set of BFD policies [RFC5880] that can be
invoked when building a VPN service. invoked when building a VPN service.
'forwarding-profile-identifier': A forwarding profile refers to the 'forwarding-profile-identifier': A forwarding profile refers to the
policies that apply to the forwarding of packets conveyed within a policies that apply to the forwarding of packets conveyed within a
VPN. Such policies may consist, for example, of applying ACLs. VPN. Such policies may consist of, for example, applying ACLs.
'routing-profile-identifier': A routing profile refers to a set of 'routing-profile-identifier': A routing profile refers to a set of
routing policies that will be invoked (e.g., BGP policies) when routing policies that will be invoked (e.g., BGP policies) when
delivering the VPN service. delivering the VPN service.
7.3. VPN Services 7.3. VPN Services
The 'vpn-service' is the data structure that abstracts an L2VPN The 'vpn-service' is the data structure that abstracts an L2VPN
service in the service provider network. Each 'vpn-service' is service in the service provider network. Each 'vpn-service' is
uniquely identified by an identifier: 'vpn-id'. Such a 'vpn-id' is uniquely identified by an identifier: 'vpn-id'. Such a 'vpn-id' is
only meaningful locally within the network controller. The subtree only meaningful locally within the network controller. The subtree
of the 'vpn-services' is shown in Figure 6. of the 'vpn-services' is shown in Figure 6.
+--rw vpn-services +--rw vpn-services
+--rw vpn-service* [vpn-id] +--rw vpn-service* [vpn-id]
+--rw vpn-id vpn-common:vpn-id +--rw vpn-id vpn-common:vpn-id
+--rw vpn-name? string +--rw vpn-name? string
+--rw vpn-description? string +--rw vpn-description? string
+--rw customer-name? string +--rw customer-name? string
+--rw parent-service-id? vpn-common:vpn-id +--rw parent-service-id? vpn-common:vpn-id
+--rw vpn-type? identityref +--rw vpn-type? identityref
+--rw vpn-service-topology? identityref +--rw vpn-service-topology? identityref
+--rw bgp-ad-enabled? boolean +--rw bgp-ad-enabled? boolean
+--rw signaling-type? identityref +--rw signaling-type? identityref
+--rw global-parameters-profiles +--rw global-parameters-profiles
| ... | ...
+--rw underlay-transport +--rw underlay-transport
| +--rw (type)? | +--rw (type)?
| +--:(abstract) | +--:(abstract)
| | +--rw transport-instance-id? string | | +--rw transport-instance-id? string
| | +--rw instance-type? identityref | | +--rw instance-type? identityref
| +--:(protocol) | +--:(protocol)
| +--rw protocol* identityref | +--rw protocol* identityref
+--rw status +--rw status
| +--rw admin-status | +--rw admin-status
| | +--rw status? identityref | | +--rw status? identityref
| | +--rw last-change? yang:date-and-time | | +--rw last-change? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-change? yang:date-and-time | +--ro last-change? yang:date-and-time
+--rw vpn-nodes +--rw vpn-nodes
... ...
Figure 6: VPN Services Subtree Figure 6: VPN Services Subtree
The descriptions of the VPN service data nodes that are depicted in The descriptions of the VPN service data nodes that are depicted in
Figure 6 are as follows: Figure 6 are as follows:
'vpn-id': An identifier that is used to uniquely identify the L2VPN 'vpn-id': An identifier that is used to uniquely identify the L2VPN
service within the L2NM scope. service within the L2NM scope.
'vpn-name': Associates a name with the service in order to 'vpn-name': Associates a name with the service in order to
skipping to change at page 19, line 6 skipping to change at line 730
'vpn-description': Includes a textual description of the service. 'vpn-description': Includes a textual description of the service.
The internal structure of a VPN description is local to each VPN The internal structure of a VPN description is local to each VPN
service provider. service provider.
'customer-name': Indicates the name of the customer who ordered the 'customer-name': Indicates the name of the customer who ordered the
service. service.
'parent-service-id': Refers to an identifier of the parent service 'parent-service-id': Refers to an identifier of the parent service
(e.g., the L2SM, IETF network slice, VPN+) that triggered the (e.g., the L2SM, IETF network slice, and VPN+) that triggered the
creation of the L2VPN service. This identifier is used to easily creation of the L2VPN service. This identifier is used to easily
correlate the (network) service as built in the network with a correlate the (network) service as built in the network with a
service order. A controller can use that correlation to enrich or service order. A controller can use that correlation to enrich or
populate some fields (e.g., description fields) as a function of populate some fields (e.g., description fields) as a function of
local deployments. local deployments.
'vpn-type': Indicates the L2VPN type. The following types, defined 'vpn-type': Indicates the L2VPN type. The following types, defined
in [RFC9181], can be used for the L2NM: in [RFC9181], can be used for the L2NM:
'vpls': Virtual Private LAN Service (VPLS) as defined in 'vpls': Virtual Private LAN Service (VPLS) as defined in
[RFC4761] or [RFC4762]. This type is also used for [RFC4761] or [RFC4762]. This type is also used for
hierarchical VPLS (H-VPLS) (Section 10 of [RFC4762]). hierarchical VPLS (H-VPLS) (Section 10 of [RFC4762]).
'vpws': Virtual Private Wire Service (VPWS) as defined in 'vpws': Virtual Private Wire Service (VPWS) as defined in
Section 3.1.1 of [RFC4664]. Section 3.1.1 of [RFC4664].
'vpws-evpn': VPWS as defined in [RFC8214]. 'vpws-evpn': VPWS EVPNs as defined in [RFC8214].
'pbb-evpn': Provider Backbone Bridging (PBB) EVPNs as defined in 'pbb-evpn': Provider Backbone Bridging (PBB) EVPNs as defined in
[RFC7623]. [RFC7623].
'mpls-evpn': MPLS-based EVPNs [RFC7432]. 'mpls-evpn': MPLS-based EVPNs [RFC7432].
'vxlan-evpn': VXLAN based EVPNs [RFC8365]. 'vxlan-evpn': VXLAN-based EVPNs [RFC8365].
The type is used as a condition for the presence of some data The type is used as a condition for the presence of some data
nodes in the L2NM. nodes in the L2NM.
'vpn-service-topology': Indicates the network topology for the 'vpn-service-topology': Indicates the network topology for the
service: hub-spoke, any-to-any, or custom. These types are service: hub-spoke, any-to-any, or custom. These types are
defined in [RFC9181]. defined in [RFC9181].
'bgp-ad-enabled': Controls whether BGP auto-discovery is enabled. 'bgp-ad-enabled': Controls whether BGP auto-discovery is enabled.
If so, additional data nodes are included (Section 7.5.1). If so, additional data nodes are included (Section 7.5.1).
skipping to change at page 19, line 52 skipping to change at line 776
'signaling-type': Indicates the signaling that is used for setting 'signaling-type': Indicates the signaling that is used for setting
up pseudowires. Signaling type values are taken from [RFC9181]. up pseudowires. Signaling type values are taken from [RFC9181].
The following signaling options are supported: The following signaling options are supported:
'bgp-signaling': The L2NM supports two flavors of BGP-signaled 'bgp-signaling': The L2NM supports two flavors of BGP-signaled
L2VPNs: L2VPNs:
'l2vpn-bgp': The service is a Multipoint VPLS that uses a BGP 'l2vpn-bgp': The service is a Multipoint VPLS that uses a BGP
control plane as described in [RFC4761] and [RFC6624]. control plane as described in [RFC4761] and [RFC6624].
'evpn-bgp': The service is a Multipoint VPLS that uses also a 'evpn-bgp': The service is a Multipoint VPLS that uses a BGP
BGP control plane, but also includes the additional EVPN control plane but also includes the additional EVPN features
features and related parameters [RFC7432] and [RFC7209]. and related parameters as described in [RFC7432] and
[RFC7209].
'ldp-signaling': A Multipoint VPLS that uses a mesh of LDP- 'ldp-signaling': A Multipoint VPLS that uses a mesh of LDP-
signaled Pseudowires [RFC6074]. signaled pseudowires [RFC6074].
'l2tp-signaling': The L2NM uses L2TP-signaled Pseudowires as 'l2tp-signaling': The L2NM uses L2TP-signaled pseudowires as
described in [RFC6074]. described in [RFC6074].
Table 1 summarizes the allowed signaling types for each VPN Table 1 summarizes the allowed signaling types for each VPN
service type ('vpn-type'). See Section 7.5.2 for more details. service type ('vpn-type'). See Section 7.5.2 for more details.
+============+================================+ +============+================================+
| VPN Type | Signaling Options | | VPN Type | Signaling Options |
+============+================================+ +============+================================+
| vpls | l2tp-signaling, ldp-signaling, | | vpls | l2tp-signaling, ldp-signaling, |
| | bgp-signaling (l2vpn-bgp) | | | bgp-signaling (l2vpn-bgp) |
skipping to change at page 20, line 34 skipping to change at line 808
+------------+--------------------------------+ +------------+--------------------------------+
| vpws-evpn | bgp-signaling (evpn-bgp) | | vpws-evpn | bgp-signaling (evpn-bgp) |
+------------+--------------------------------+ +------------+--------------------------------+
| pbb-evpn | bgp-signaling (evpn-bgp) | | pbb-evpn | bgp-signaling (evpn-bgp) |
+------------+--------------------------------+ +------------+--------------------------------+
| mpls-evpn | bgp-signaling (evpn-bgp) | | mpls-evpn | bgp-signaling (evpn-bgp) |
+------------+--------------------------------+ +------------+--------------------------------+
| vxlan-evpn | bgp-signaling (evpn-bgp) | | vxlan-evpn | bgp-signaling (evpn-bgp) |
+------------+--------------------------------+ +------------+--------------------------------+
Table 1: Signaling Options per VPN Table 1: Signaling Options per VPN Service Type
Service Type
'global-parameters-profiles': Defines reusable parameters for the 'global-parameters-profiles': Defines reusable parameters for the
same L2VPN service. same L2VPN service.
More details are provided in Section 7.4. More details are provided in Section 7.4.
'underlay-transport': Describes the preference for the transport 'underlay-transport': Describes the preference for the transport
technology to carry the traffic of the VPN service. This technology to carry the traffic of the VPN service. This
preference is especially useful in networks with multiple domains preference is especially useful in networks with multiple domains
and Network-to-Network Interface (NNI) types. The underlay and Network-to-Network Interface (NNI) types. The underlay
transport can be expressed as an abstract transport instance transport can be expressed as an abstract transport instance
(e.g., an identifier of a VPN+ instance, a virtual network (e.g., an identifier of a VPN+ instance, a virtual network
identifier, or a network slice name) or as an ordered list of the identifier, or a network slice name) or as an ordered list of the
actual protocols to be enabled in the network. actual protocols to be enabled in the network.
A rich set of protocol identifiers that can be used to refer to an A rich set of protocol identifiers that can be used to refer to an
underlay transport (or how such an underlay is set up) are defined underlay transport (or how such an underlay is set up) are defined
in [RFC9181]. in [RFC9181].
The model defined in Section 6.3.2 of The model defined in Section 6.3.2 of [TE-SERVICE-MAPPING] may be
[I-D.ietf-teas-te-service-mapping-yang] may be used if specific used if specific protection and availability requirements are
protection and availability requirements are needed between PEs. needed between PEs.
'status': Used to track the overall status of a given VPN service. 'status': Used to track the overall status of a given VPN service.
Both operational and administrative status are maintained together Both operational and administrative status are maintained together
with a timestamp. For example, a service can be created, but not with a timestamp. For example, a service can be created but not
put into effect. put into effect.
Administrative and operational status can be used as a trigger to Administrative and operational status can be used as a trigger to
detect service anomalies. For example, a service that is declared detect service anomalies. For example, a service that is declared
at the service layer as being created but still inactive at the at the service layer as being created but still inactive at the
network layer is an indication that network provisioning actions network layer is an indication that network provisioning actions
are needed to align the observed service status with the expected are needed to align the observed service status with the expected
service status. service status.
'vpn-node': An abstraction that represents a set of policies applied 'vpn-node': An abstraction that represents a set of policies applied
skipping to change at page 21, line 39 skipping to change at line 858
A 'vpn-node' contains 'vpn-network-accesses', which are the A 'vpn-node' contains 'vpn-network-accesses', which are the
interfaces attached to the VPN by which the customer traffic is interfaces attached to the VPN by which the customer traffic is
received. Therefore, the customer sites are connected to the received. Therefore, the customer sites are connected to the
'vpn-network-accesses'. 'vpn-network-accesses'.
Note that, as this is a network data model, the information about Note that, as this is a network data model, the information about
customers sites is not required in the model. Such information is customers sites is not required in the model. Such information is
rather relevant in the L2SM. Whether that information is included rather relevant in the L2SM. Whether that information is included
in the L2NM, e.g., to populate the various 'description' data in the L2NM, e.g., to populate the various 'description' data
nodes is implementation specific. nodes, is implementation specific.
More details are provided in Section 7.5. More details are provided in Section 7.5.
7.4. Global Parameters Profiles 7.4. Global Parameters Profiles
The 'global-parameters-profile' defines reusable parameters for the The 'global-parameters-profile' defines reusable parameters for the
same L2VPN service instance ('vpn-service'). Global parameters same L2VPN service instance ('vpn-service'). Global parameters
profiles are defined at the VPN service level, activated at the VPN profiles are defined at the VPN service level, activated at the VPN
node level, and then an activated VPN profile may be used at the VPN node level, and then an activated VPN profile may be used at the VPN
network access level. Each VPN instance profile is identified by network access level. Each VPN instance profile is identified by
'profile-id'. Some of the data nodes can be adjusted at the VPN node 'profile-id'. Some of the data nodes can be adjusted at the VPN node
or VPN network access levels. These adjusted values take precedence or VPN network access levels. These adjusted values take precedence
over the global values. The subtree of 'global-parameters-profile' over the global values. The subtree of 'global-parameters-profile'
is depicted in Figure 7. is depicted in Figure 7.
... ...
+--rw vpn-services +--rw vpn-services
+--rw vpn-service* [vpn-id] +--rw vpn-service* [vpn-id]
... ...
+--rw global-parameters-profiles +--rw global-parameters-profiles
| +--rw global-parameters-profile* [profile-id] | +--rw global-parameters-profile* [profile-id]
| +--rw profile-id string | +--rw profile-id string
| +--rw (rd-choice)? | +--rw (rd-choice)?
| | +--:(directly-assigned) | | +--:(directly-assigned)
| | | +--rw rd? | | | +--rw rd?
| | | rt-types:route-distinguisher | | | rt-types:route-distinguisher
| | +--:(directly-assigned-suffix) | | +--:(directly-assigned-suffix)
| | | +--rw rd-suffix? uint16 | | | +--rw rd-suffix? uint16
| | +--:(auto-assigned) | | +--:(auto-assigned)
| | | +--rw rd-auto | | | +--rw rd-auto
| | | +--rw (auto-mode)? | | | +--rw (auto-mode)?
| | | | +--:(from-pool) | | | | +--:(from-pool)
| | | | | +--rw rd-pool-name? string | | | | | +--rw rd-pool-name? string
| | | | +--:(full-auto) | | | | +--:(full-auto)
| | | | +--rw auto? empty | | | | +--rw auto? empty
| | | +--ro auto-assigned-rd? | | | +--ro auto-assigned-rd?
| | | rt-types:route-distinguisher | | | rt-types:route-distinguisher
| | +--:(auto-assigned-suffix) | | +--:(auto-assigned-suffix)
| | | +--rw rd-auto-suffix | | | +--rw rd-auto-suffix
| | | +--rw (auto-mode)? | | | +--rw (auto-mode)?
| | | | +--:(from-pool) | | | | +--:(from-pool)
| | | | | +--rw rd-pool-name? string | | | | | +--rw rd-pool-name? string
| | | | +--:(full-auto) | | | | +--:(full-auto)
| | | | +--rw auto? empty | | | | +--rw auto? empty
| | | +--ro auto-assigned-rd-suffix? uint16 | | | +--ro auto-assigned-rd-suffix? uint16
| | +--:(no-rd) | | +--:(no-rd)
| | +--rw no-rd? empty | | +--rw no-rd? empty
| +--rw vpn-target* [id] | +--rw vpn-target* [id]
| | +--rw id uint8 | | +--rw id uint8
| | +--rw route-targets* [route-target] | | +--rw route-targets* [route-target]
| | | +--rw route-target rt-types:route-target | | | +--rw route-target rt-types:route-target
| | +--rw route-target-type | | +--rw route-target-type
| | rt-types:route-target-type | | rt-types:route-target-type
| +--rw vpn-policies | +--rw vpn-policies
| | +--rw import-policy? string | | +--rw import-policy? string
| | +--rw export-policy? string | | +--rw export-policy? string
| +--rw local-autonomous-system? inet:as-number | +--rw local-autonomous-system? inet:as-number
| +--rw svc-mtu? uint32 | +--rw svc-mtu? uint32
| +--rw ce-vlan-preservation? boolean | +--rw ce-vlan-preservation? boolean
| +--rw ce-vlan-cos-preservation? boolean | +--rw ce-vlan-cos-preservation? boolean
| +--rw control-word-negotiation? boolean | +--rw control-word-negotiation? boolean
| +--rw mac-policies | +--rw mac-policies
| | +--rw mac-addr-limit | | +--rw mac-addr-limit
| | | +--rw limit-number? uint16 | | | +--rw limit-number? uint16
| | | +--rw time-interval? uint32 | | | +--rw time-interval? uint32
| | | +--rw action? identityref | | | +--rw action? identityref
| | +--rw mac-loop-prevention | | +--rw mac-loop-prevention
| | +--rw window? uint32 | | +--rw window? uint32
| | +--rw frequency? uint32 | | +--rw frequency? uint32
| | +--rw retry-timer? uint32 | | +--rw retry-timer? uint32
| | +--rw protection-type? identityref | | +--rw protection-type? identityref
| +--rw multicast {vpn-common:multicast}? | +--rw multicast {vpn-common:multicast}?
| +--rw enabled? boolean | +--rw enabled? boolean
| +--rw customer-tree-flavors | +--rw customer-tree-flavors
| +--rw tree-flavor* identityref | +--rw tree-flavor* identityref
... ...
Figure 7: Global Parameters Profiles Subtree Figure 7: Global Parameters Profiles Subtree
The description of the global parameters profile is as follows: The description of the global parameters profile is as follows:
'profile-id': Uniquely identifies a global parameter profile in the 'profile-id': Uniquely identifies a global parameter profile in the
context of an L2VPN service. context of an L2VPN service.
'rd': As defined in [RFC9181], these RD assignment modes are 'rd': As defined in [RFC9181], these RD assignment modes are
supported: direct assignment, automatic assignment from a given supported: direct assignment, automatic assignment from a given
pool, full automatic assignment, and no assignment. pool, full automatic assignment, and no assignment.
Also, the module accommodates deployments where only the Assigned Also, the module accommodates deployments where only the Assigned
Number subfield of RDs is assigned from a pool while the Number subfield of RDs is assigned from a pool while the
Administrator subfield is set to, e.g., the Router ID that is Administrator subfield is set to, e.g., the Router ID that is
assigned to a VPN node. The module supports these modes for assigned to a VPN node. The module supports these modes to manage
managing the Assigned Number subfield: explicit assignment, auto- the Assigned Number subfield: explicit assignment, auto-assignment
assignment from a pool, and full auto-assignment. from a pool, and full auto-assignment.
'vpn-targets': Specifies RT import/export rules for the VPN service. 'vpn-targets': Specifies RT import/export rules for the VPN service.
'local-autonomous-system': Indicates the Autonomous System Number 'local-autonomous-system': Indicates the Autonomous System Number
(ASN) that is configured for the VPN node. The ASN can be used to (ASN) that is configured for the VPN node. The ASN can be used to
auto-derive some other attributes such as RDs or Ethernet Segment auto-derive some other attributes such as RDs or Ethernet Segment
Identifiers (ESIs). Identifiers (ESIs).
'svc-mtu': Is the service MTU for an L2VPN service (i.e., Layer 2 'svc-mtu': Is the service MTU for an L2VPN service (i.e., a Layer 2
MTU including L2 frame header/trailer). It is also known as the MTU including an L2 frame header/trailer). It is also known as
maximum transmission unit or maximum frame size. It is expressed the maximum transmission unit or maximum frame size. It is
in bytes. expressed in bytes.
'ce-vlan-preservation': Is set to preserve the Customer Edge VLAN 'ce-vlan-preservation': Is set to preserve the Customer Edge VLAN
IDs (CE-VLAN IDs) from ingress to egress, i.e., CE-VLAN tag of the (CE VLAN) IDs from ingress to egress, i.e., CE VLAN tags of the
egress frame are identical to those of the ingress frame that egress frame are identical to those of the ingress frame that
yielded this egress service frame. If all-to-one bundling within yielded this egress service frame. If all-to-one bundling within
a site is enabled, then preservation applies to all ingress a site is enabled, then preservation applies to all ingress
service frames. If all-to-one bundling is disabled, then service frames. If all-to-one bundling is disabled, then
preservation applies to tagged Ingress service frames having CE- preservation applies to tagged Ingress service frames having CE
VLAN ID 1 through 4094. VLAN ID 1 through 4094.
'ce-vlan-cos-preservation': Controls the CE VLAN CoS preservation. 'ce-vlan-cos-preservation': Controls the CE VLAN Class of Service
When set, Priority Code Point (PCP) bits in the CE-VLAN tag of the (CoS) preservation. When set, Priority Code Point (PCP) bits in
egress frame are identical to those of the ingress frame that the CE VLAN tag of the egress frame are identical to those of the
yielded this egress service frame. ingress frame that yielded this egress service frame.
'control-word-negotiation': Controls whether control-word 'control-word-negotiation': Controls whether control-word
negotiation is enabled (if set to true) or not (if set to false). negotiation is enabled (if set to true) or not (if set to false).
Refer to Section 7 of [RFC8077] for more details. Refer to Section 7 of [RFC8077] for more details.
'mac-policies': Includes a set of MAC policies that apply to the 'mac-policies': Includes a set of MAC policies that apply to the
service: service:
'mac-addr-limit': Is a container of MAC address limit 'mac-addr-limit': Is a container of MAC address limit
configuration. It includes the following data nodes: configuration. It includes the following data nodes:
skipping to change at page 25, line 10 skipping to change at line 1020
the duplicate MAC address will be flushed from the MAC-VRF. the duplicate MAC address will be flushed from the MAC-VRF.
'protection-type': It defines the loop prevention type (e.g., 'protection-type': It defines the loop prevention type (e.g.,
shut). shut).
'multicast': Controls whether multicast is allowed in the service. 'multicast': Controls whether multicast is allowed in the service.
7.5. VPN Nodes 7.5. VPN Nodes
The 'vpn-node' (Figure 8) is an abstraction that represents a set of The 'vpn-node' (Figure 8) is an abstraction that represents a set of
policies/configurations applied to a network node and that belong to policies applied to a network node that belongs to a single 'vpn-
a single 'vpn-service'. A 'vpn-node' contains 'vpn-network- service'. A 'vpn-node' contains 'vpn-network-accesses', which are
accesses', which are the interfaces involved in the creation of the the interfaces involved in the creation of the VPN. The customer
VPN. The customer sites are connected to the 'vpn-network-accesses'. sites are connected to the 'vpn-network-accesses'.
+--rw l2vpn-ntw +--rw l2vpn-ntw
+--rw vpn-profiles +--rw vpn-profiles
| ... | ...
+--rw vpn-services +--rw vpn-services
+--rw vpn-service* [vpn-id] +--rw vpn-service* [vpn-id]
... ...
+--rw vpn-nodes +--rw vpn-nodes
+--rw vpn-node* [vpn-node-id] +--rw vpn-node* [vpn-node-id]
+--rw vpn-node-id vpn-common:vpn-id +--rw vpn-node-id vpn-common:vpn-id
+--rw description? string +--rw description? string
+--rw ne-id? string +--rw ne-id? string
+--rw role? identityref +--rw role? identityref
+--rw router-id? rt-types:router-id +--rw router-id? rt-types:router-id
+--rw active-global-parameters-profiles +--rw active-global-parameters-profiles
| +--rw global-parameters-profile* [profile-id] | +--rw global-parameters-profile* [profile-id]
| +--rw profile-id leafref | +--rw profile-id leafref
| +--rw local-autonomous-system? | +--rw local-autonomous-system?
| | inet:as-number | | inet:as-number
| +--rw svc-mtu? uint32 | +--rw svc-mtu? uint32
| +--rw ce-vlan-preservation? boolean | +--rw ce-vlan-preservation? boolean
| +--rw ce-vlan-cos-preservation? boolean | +--rw ce-vlan-cos-preservation? boolean
| +--rw control-word-negotiation? boolean | +--rw control-word-negotiation? boolean
| +--rw mac-policies | +--rw mac-policies
| | +--rw mac-addr-limit | | +--rw mac-addr-limit
| | | +--rw limit-number? uint16 | | | +--rw limit-number? uint16
| | | +--rw time-interval? uint32 | | | +--rw time-interval? uint32
| | | +--rw action? identityref | | | +--rw action? identityref
| | +--rw mac-loop-prevention | | +--rw mac-loop-prevention
| | +--rw window? uint32 | | +--rw window? uint32
| | +--rw frequency? uint32 | | +--rw frequency? uint32
| | +--rw retry-timer? uint32 | | +--rw retry-timer? uint32
| | +--rw protection-type? identityref | | +--rw protection-type? identityref
| +--rw multicast {vpn-common:multicast}? | +--rw multicast {vpn-common:multicast}?
| +--rw enabled? boolean | +--rw enabled? boolean
| +--rw customer-tree-flavors | +--rw customer-tree-flavors
| +--rw tree-flavor* identityref | +--rw tree-flavor* identityref
+--rw status +--rw status
| ... | ...
+--rw bgp-auto-discovery +--rw bgp-auto-discovery
| ... | ...
+--rw signaling-option +--rw signaling-option
| ... | ...
+--rw vpn-network-accesses +--rw vpn-network-accesses
... ...
Figure 8: VPN Nodes Subtree Figure 8: VPN Nodes Subtree
The descriptions of VPN node data nodes are as follows: The descriptions of VPN node data nodes are as follows:
'vpn-node-id': Used to uniquely identify a node that enables a VPN 'vpn-node-id': Used to uniquely identify a node that enables a VPN
network access. network access.
'description': Provides a textual description of the VPN node. 'description': Provides a textual description of the VPN node.
'ne-id': Includes an identifier of the network element where the VPN 'ne-id': Includes an identifier of the network element where the VPN
node is deployed. node is deployed.
'role': Indicates the role of the VPN instance profile in the VPN. 'role': Indicates the role of the VPN instance profile in the VPN.
Role values are defined in [RFC9181] (e.g., 'any-to-any-role', Role values are defined in [RFC9181] (e.g., 'any-to-any-role',
'spoke-role', 'hub-role'). 'spoke-role', and 'hub-role').
'router-id': Indicates a 32-bit number that is used to uniquely 'router-id': Indicates a 32-bit number that is used to uniquely
identify a router within an Autonomous System (AS). identify a router within an AS.
'active-global-parameters-profiles': Lists the set of active global 'active-global-parameters-profiles': Lists the set of active global
VPN parameters profiles for this VPN node. Concretely, one or VPN parameter profiles for this VPN node. Concretely, one or more
more global profiles that are defined at the VPN service level global profiles that are defined at the VPN service level (i.e.,
(i.e., under 'l2vpn-ntw/vpn-services/vpn-service' level) can be under 'l2vpn-ntw/vpn-services/vpn-service' level) can be activated
activated at the VPN node level; each of these profiles is at the VPN node level; each of these profiles is uniquely
uniquely identified by means of 'profile-id'. The structure of identified by means of 'profile-id'. The structure of 'active-
'active-global-parameters-profiles' uses the same data nodes as global-parameters-profiles' uses the same data nodes as
Section 7.4 except RD and RT related data nodes. Section 7.4 with the exception of the data nodes related to RD and
RT.
Values defined in 'active-global-parameters-profiles' overrides Values defined in 'active-global-parameters-profiles' override the
the values defined in the VPN service level. values defined in the VPN service level.
'status': Tracks the status of a node involved in a VPN service. 'status': Tracks the status of a node involved in a VPN service.
Both operational and administrative status are maintained. A Both operational and administrative status are maintained. A
mismatch between the administrative status vs. the operational mismatch between the administrative status vs. the operational
status can be used as a trigger to detect anomalies. status can be used as a trigger to detect anomalies.
'bgp-auto-discovery': See Section 7.5.1. 'bgp-auto-discovery': See Section 7.5.1.
'signaling-option': See Section 7.5.2. 'signaling-option': See Section 7.5.2.
'vpn-network-accesses': Represents the point to which sites are 'vpn-network-accesses': Represents the point to which sites are
connected. connected.
Note that, unlike the L2SM, the L2NM does not need to model the Note that, unlike the L2SM, the L2NM does not need to model the
customer site -- only the points that receive traffic from the customer site; only the points that receive traffic from the site
site are covered (i.e., the PE side of Provider Edge to Customer are covered (i.e., the PE side of Provider Edge to Customer Edge
Edge (PE-CE) connections). Hence, the VPN network access contains (PE-CE) connections). Hence, the VPN network access contains the
the connectivity information between the provider's network and connectivity information between the provider's network and the
the customer premises. The VPN profiles ('vpn-profiles') have a customer premises. The VPN profiles ('vpn-profiles') have a set
set of routing policies that can be applied during the service of routing policies that can be applied during the service
creation. creation.
See Section 7.6 for more details. See Section 7.6 for more details.
7.5.1. BGP Auto-Discovery 7.5.1. BGP Auto-Discovery
The 'bgp-auto-discovery' container (Figure 9) includes the required The 'bgp-auto-discovery' container (Figure 9) includes the required
information for the activation of BGP auto-discovery information for the activation of BGP auto-discovery
[RFC4761][RFC6624]. [RFC4761][RFC6624].
skipping to change at page 29, line 24 skipping to change at line 1191
| +--rw vpn-policies | +--rw vpn-policies
| +--rw import-policy? string | +--rw import-policy? string
| +--rw export-policy? string | +--rw export-policy? string
+--rw signaling-option +--rw signaling-option
| ... | ...
+--rw vpn-network-accesses +--rw vpn-network-accesses
... ...
Figure 9: BGP Auto-Discovery Subtree Figure 9: BGP Auto-Discovery Subtree
As discussed in Section 1 of [RFC6624], all of BGP-based methods As discussed in Section 1 of [RFC6624], all BGP-based methods include
include the notion of a VPN identifier that serves to unify the notion of a VPN identifier that serves to unify components of a
components of a given VPN and the concept of auto-discovery; hence given VPN and the concept of auto-discovery, hence the support of the
the support of the data node 'vpn-id'. data node 'vpn-id'.
For the particular case of EVPN, the L2NM supports RT auto-derivation 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 based on the Ethernet Tag ID specified in Section 7.10.1 of
[RFC7432]. A VPN service provider can enable/disable this [RFC7432]. A VPN service provider can enable/disable this
functionality by means of 'auto-rt-enable'. The assigned RT can be functionality by means of 'auto-rt-enable'. The assigned RT can be
retrieved using 'auto-route-target'. retrieved using 'auto-route-target'.
For all BGP-based L2VPN flavors, other data nodes such as RD and RT 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 are used. These data nodes have the same structure as the one
discussed in Section 7.4. discussed in Section 7.4.
7.5.2. Signaling Options 7.5.2. Signaling Options
The 'signaling-option' container (Figure 10) defines a set of data The 'signaling-option' container (Figure 10) defines a set of data
nodes for a given signaling protocol that is used for an L2VPN nodes for a given signaling protocol that is used for an L2VPN
service. As discussed in Section 7.3, several signaling options to service. As discussed in Section 7.3, several signaling options to
exchange membership information between PEs of an L2VPN are exchange membership information between PEs of an L2VPN are
supported. The signaling type to be used for an L2VPN service is supported. The signaling type to be used for an L2VPN service is
controlled at the VPN service level by means of 'signaling-type'. controlled at the VPN service level by means of 'signaling-type'.
... ...
+--rw vpn-nodes +--rw vpn-nodes
+--rw vpn-node* [vpn-node-id] +--rw vpn-node* [vpn-node-id]
... ...
+--rw signaling-option +--rw signaling-option
| +--rw advertise-mtu? boolean | +--rw advertise-mtu? boolean
| +--rw mtu-allow-mismatch? boolean | +--rw mtu-allow-mismatch? boolean
| +--rw signaling-type? leafref | +--rw signaling-type? leafref
| +--rw (signaling-option)? | +--rw (signaling-option)?
| +--:(bgp) | +--:(bgp)
| | ... | | ...
| +--:(ldp-or-l2tp) | +--:(ldp-or-l2tp)
| +--rw ldp-or-l2tp | +--rw ldp-or-l2tp
| ... | ...
| +--rw (ldp-or-l2tp)? | +--rw (ldp-or-l2tp)?
| +--:(ldp) | +--:(ldp)
| | ... | | ...
| +--:(l2tp) | +--:(l2tp)
| ... | ...
Figure 10: Signaling Option Overall Subtree Figure 10: Signaling Option Overall Subtree
The following signaling data nodes are supported: The following signaling data nodes are supported:
'advertise-mtu': Controls whether MTU is advertised when setting a 'advertise-mtu': Controls whether MTU is advertised when setting a
pseudowire (e.g., Section 4.3 of [RFC4667], Section 5.1 of pseudowire (e.g., Section 4.3 of [RFC4667], Section 5.1 of
[RFC6624], or Section 6.1 of [RFC4762]). [RFC6624], or Section 6.1 of [RFC4762]).
'mtu-allow-mismatch': When set to true, it allows MTU mismatch for a 'mtu-allow-mismatch': When set to true, it allows an MTU mismatch
pseudowire (see, e.g., Section 4.3 of [RFC4667]). for a pseudowire (see, e.g., Section 4.3 of [RFC4667]).
'signaling-type': Indicates the signaling type. This type inherits 'signaling-type': Indicates the signaling type. This type inherits
the value of 'signaling-type' defined at the service level the value of 'signaling-type' defined at the service level
(Section 7.3). (Section 7.3).
'bgp': Is provided when BGP is used for L2VPN signaling. Refer to 'bgp': Is provided when BGP is used for L2VPN signaling. Refer to
Section 7.5.2.1 for more details. Section 7.5.2.1 for more details.
'ldp': The model supports the configuration of the parameters that 'ldp': The model supports the configuration of the parameters that
are discussed in Section 6 of [RFC4762]. Refer to Section 7.5.2.2 are discussed in Section 6 of [RFC4762]. Refer to Section 7.5.2.2
skipping to change at page 31, line 13 skipping to change at line 1269
for more details. for more details.
Note that LDP and L2TP choices are bundled ("ldp-or-l2tp") because Note that LDP and L2TP choices are bundled ("ldp-or-l2tp") because
they share a set of common parameters that are further detailed in they share a set of common parameters that are further detailed in
Sections 7.5.2.2 and 7.5.2.3. Sections 7.5.2.2 and 7.5.2.3.
7.5.2.1. BGP 7.5.2.1. BGP
The structure of the BGP-related data nodes is provided in Figure 11. The structure of the BGP-related data nodes is provided in Figure 11.
... ...
| +--rw (signaling-option)? | +--rw (signaling-option)?
| ... | ...
| +--:(bgp) | +--:(bgp)
| | +--rw (bgp-type)? | | +--rw (bgp-type)?
| | +--:(l2vpn-bgp) | | +--:(l2vpn-bgp)
| | | +--rw ce-range? uint16 | | | +--rw ce-range? uint16
| | | +--rw pw-encapsulation-type? | | | +--rw pw-encapsulation-type?
| | | | identityref | | | | identityref
| | | +--rw vpls-instance | | | +--rw vpls-instance
| | | +--rw vpls-edge-id? uint16 | | | +--rw vpls-edge-id? uint16
| | | +--rw vpls-edge-id-range? uint16 | | | +--rw vpls-edge-id-range? uint16
| | +--:(evpn-bgp) | | +--:(evpn-bgp)
| | +--rw evpn-type? leafref | | +--rw evpn-type? leafref
| | +--rw service-interface-type? | | +--rw service-interface-type?
| | | identityref | | | identityref
| | +--rw evpn-policies | | +--rw evpn-policies
| | +--rw mac-learning-mode? | | +--rw mac-learning-mode?
| | | identityref | | | identityref
| | +--rw ingress-replication? | | +--rw ingress-replication?
| | | boolean | | | boolean
| | +--rw p2mp-replication? | | +--rw p2mp-replication?
| | | boolean | | | boolean
| | +--rw arp-proxy {vpn-common:ipv4}? | | +--rw arp-proxy {vpn-common:ipv4}?
| | | +--rw enable? boolean | | | +--rw enable? boolean
| | | +--rw arp-suppression? | | | +--rw arp-suppression?
| | | | boolean | | | | boolean
| | | +--rw ip-mobility-threshold? | | | +--rw ip-mobility-threshold?
| | | | uint16 | | | | uint16
| | | +--rw duplicate-ip-detection-interval? | | | +--rw duplicate-ip-detection-interval?
| | | uint16 | | | uint16
| | +--rw nd-proxy {vpn-common:ipv6}? | | +--rw nd-proxy {vpn-common:ipv6}?
| | | +--rw enable? boolean | | | +--rw enable? boolean
| | | +--rw nd-suppression? | | | +--rw nd-suppression?
| | | | boolean | | | | boolean
| | | +--rw ip-mobility-threshold? | | | +--rw ip-mobility-threshold?
| | | | uint16 | | | | uint16
| | | +--rw duplicate-ip-detection-interval? | | | +--rw duplicate-ip-detection-interval?
| | | uint16 | | | uint16
| | +--rw underlay-multicast? | | +--rw underlay-multicast?
| | | boolean | | | boolean
| | +--rw flood-unknown-unicast-supression? | | +--rw flood-unknown-unicast-suppression?
| | | boolean | | | boolean
| | +--rw vpws-vlan-aware? boolean | | +--rw vpws-vlan-aware? boolean
| | +--rw bum-management | | +--rw bum-management
| | | +--rw discard-broadcast? | | | +--rw discard-broadcast?
| | | | boolean | | | | boolean
| | | +--rw discard-unknown-multicast? | | | +--rw discard-unknown-multicast?
| | | | boolean | | | | boolean
| | | +--rw discard-unknown-unicast? | | | +--rw discard-unknown-unicast?
| | | boolean | | | boolean
| | +--rw pbb | | +--rw pbb
| | +--rw backbone-src-mac? | | +--rw backbone-src-mac?
| | yang:mac-address | | yang:mac-address
| +--:(ldp-or-l2tp) | +--:(ldp-or-l2tp)
| ... | ...
Figure 11: Signaling Option Subtree (BGP) Figure 11: Signaling Option Subtree (BGP)
Remote CEs that are entitled to connect to the same VPN should fit 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 with the CE range ('ce-range') as discussed in Section 2.2.3 of
[RFC6624]. 'pw-encapsulation-type' is used to control the pseudowire [RFC6624]. 'pw-encapsulation-type' is used to control the pseudowire
encapsulation type (Section 3 of [RFC6624]). The value of the 'pw- encapsulation type (Section 3 of [RFC6624]). The value of the 'pw-
encapsulation-type' are taken from the IANA-maintained "iana-bgp- encapsulation-type' is taken from the IANA-maintained "iana-bgp-
l2-encaps" module (Section 8.1). l2-encaps" module (Section 8.1).
For the specific case of VPLS, the VPLS Edge ID (VE ID, 'vpls-edge- For the specific case of VPLS, the VPLS Edge Identifier (VE ID)
id') and a VE ID range ('vpls-edge-id-range') are provided as per ('vpls-edge-id') and a VE ID range ('vpls-edge-id-range') are
Section 3.2 of [RFC4761]. If different VE IDs are required (e.g., provided as per Section 3.2 of [RFC4761]. If different VE IDs are
multihoming as per Section 3.5 of [RFC4761]), these IDs are required (e.g., multihoming as per Section 3.5 of [RFC4761]), these
configured at the VPN network access level (under 'signaling-option' IDs are configured at the VPN network access level (under 'signaling-
in Section 7.6). option' in Section 7.6).
For EVPN-related L2VPNs, 'service-interface-type' indicates whether For EVPN-related L2VPNs, 'service-interface-type' indicates whether
this is a VLAN-based, VLAN bundle, or VLAN-aware bundle service this is a VLAN-based, VLAN-aware, or VLAN bundle service interface
interface (Section 6 of [RFC7432]). Moreover, a set of policies can (Section 6 of [RFC7432]). Moreover, a set of policies can be
be provided such as MAC address learning mode (Section 9 of provided such as the MAC address learning mode (Section 9 of
[RFC7432]), ingress replication (Section 12.1 of [RFC7432]), Address [RFC7432]), ingress replication (Section 12.1 of [RFC7432]), the
Resolution Protocol (ARP) and Nighbor Discovery (ND) proxy Address Resolution Protocol (ARP) and Neighbor Discovery (ND) proxy
(Section 10 of [RFC7432]), processing of Broadcast, unknown unicast, (Section 10 of [RFC7432]), the processing of Broadcast, Unknown
or multicast (BUM) (Section 12 of [RFC7432]), etc. Unicast, or Multicast (BUM) (Section 12 of [RFC7432]), etc.
7.5.2.2. LDP 7.5.2.2. LDP
The model supports the configuration of the parameters that are The L2NM supports the configuration of the parameters that are
discussed in Section 6 of [RFC4762]. Such parameters include an discussed in Section 6 of [RFC4762]. Such parameters include an
Attachment Group Identifier (AGI) (a.k.a., VPLS-id), a Source Attachment Group Identifier (AGI) (a.k.a., VPLS-id), a Source
Attachment Individual Identifier (SAII), a list of peers that are Attachment Individual Identifier (SAII), a list of peers that are
associated with a Target Attachment Individual Identifier (TAII), a associated with a Target Attachment Individual Identifier (TAII), a
pseudowire type, and a pseudowire description (Figure 12). Unlike pseudowire type, and a pseudowire description (Figure 12). Unlike
BGP, only Ethernet and Ethernet tagged mode are supported. The AGI, BGP, only Ethernet and Ethernet tagged mode are supported. The AGI,
SAII, and TAII are encoded following the types defined in Section 3.4 SAII, and TAII are encoded following the types defined in Section 3.4
of [RFC4446]. of [RFC4446].
... ...
| +--rw (signaling-option)? | +--rw (signaling-option)?
| ... | ...
| +--:(bgp) | +--:(bgp)
| | ... | | ...
| +--:(ldp-or-l2tp) | +--:(ldp-or-l2tp)
| +--rw ldp-or-l2tp | +--rw ldp-or-l2tp
| +--rw agi? | +--rw agi?
| | rt-types:route-distinguisher | | rt-types:route-distinguisher
| +--rw saii? uint32 | +--rw saii? uint32
| +--rw remote-targets* [taii] | +--rw remote-targets* [taii]
| | +--rw taii uint32 | | +--rw taii uint32
| | +--rw peer-addr inet:ip-address | | +--rw peer-addr inet:ip-address
| +--rw (ldp-or-l2tp)? | +--rw (ldp-or-l2tp)?
| +--:(ldp) | +--:(ldp)
| | +--rw t-ldp-pw-type? | | +--rw t-ldp-pw-type?
| | | identityref | | | identityref
| | +--rw pw-type? identityref | | +--rw pw-type? identityref
| | +--rw pw-description? string | | +--rw pw-description? string
| | +--rw mac-addr-withdraw? boolean | | +--rw mac-addr-withdraw? boolean
| | +--rw pw-peer-list* | | +--rw pw-peer-list*
| | | [peer-addr vc-id] | | | [peer-addr vc-id]
| | | +--rw peer-addr | | | +--rw peer-addr
| | | | inet:ip-address | | | | inet:ip-address
| | | +--rw vc-id string | | | +--rw vc-id string
| | | +--rw pw-priority? uint32 | | | +--rw pw-priority? uint32
| | +--rw qinq | | +--rw qinq
| | +--rw s-tag dot1q-types:vlanid | | +--rw s-tag dot1q-types:vlanid
| | +--rw c-tag dot1q-types:vlanid | | +--rw c-tag dot1q-types:vlanid
| +--:(l2tp) | +--:(l2tp)
| ... | ...
... ...
Figure 12: Signaling Option Subtree (LDP) Figure 12: Signaling Option Subtree (LDP)
7.5.2.3. L2TP 7.5.2.3. L2TP
The model supports the configuration of the parameters that are The L2NM supports the configuration of the parameters that are
discussed in Section 4 of [RFC4667]. Such parameters include a discussed in Section 4 of [RFC4667]. Such parameters include a
Router ID that is used to uniquely identify a PE, a pseudowire type, Router ID that is used to uniquely identify a PE, a pseudowire type,
an AGI, an SAII, and a list of peers that are associated with a TAII an AGI, an SAII, and a list of peers that are associated with a TAII
(Figure 13). The pseudowire type ('pseudowire-type') value is taken (Figure 13). The pseudowire type ('pseudowire-type') value is taken
from the IANA-maintained "iana-pseudowire-types" module from the IANA-maintained "iana-pseudowire-types" module
(Section 8.2). (Section 8.2).
... ...
| +--rw (signaling-option)? | +--rw (signaling-option)?
| ... | ...
| +--:(bgp) | +--:(bgp)
| | ... | | ...
| +--:(ldp-or-l2tp) | +--:(ldp-or-l2tp)
| +--rw ldp-or-l2tp | +--rw ldp-or-l2tp
| +--rw agi? | +--rw agi?
| | rt-types:route-distinguisher | | rt-types:route-distinguisher
| +--rw saii? uint32 | +--rw saii? uint32
| +--rw remote-targets* [taii] | +--rw remote-targets* [taii]
| | +--rw taii uint32 | | +--rw taii uint32
| | +--rw peer-addr inet:ip-address | | +--rw peer-addr inet:ip-address
| +--rw (ldp-or-l2tp)? | +--rw (ldp-or-l2tp)?
| +--:(ldp) | +--:(ldp)
| | ... | | ...
| +--:(l2tp) | +--:(l2tp)
| +--rw router-id? | +--rw router-id?
| | rt-types:router-id | | rt-types:router-id
| +--rw pseudowire-type? | +--rw pseudowire-type?
| identityref | identityref
... ...
Figure 13: Signaling Option Subtree (L2TP) Figure 13: Signaling Option Subtree (L2TP)
7.6. VPN Network Accesses 7.6. VPN Network Accesses
A 'vpn-network-access' (Figure 14) represents an entry point to a VPN A 'vpn-network-access' (Figure 14) represents an entry point to a VPN
service. In other words, this container encloses the parameters that service. In other words, this container encloses the parameters that
describe the access information for the traffic that belongs to a describe the access information for the traffic that belongs to a
particular L2VPN. particular L2VPN.
A 'vpn-network-access' includes information such as the connection on A 'vpn-network-access' includes information such as the connection on
which the access is defined, the specific Layer 2 service which the access is defined, the specific Layer 2 service
requirements, etc. requirements, etc.
... ...
+--rw vpn-nodes +--rw vpn-nodes
+--rw vpn-node* [vpn-node-id] +--rw vpn-node* [vpn-node-id]
... ...
+--rw vpn-network-accesses +--rw vpn-network-accesses
+--rw vpn-network-access* [id] +--rw vpn-network-access* [id]
+--rw id vpn-common:vpn-id +--rw id vpn-common:vpn-id
+--rw description? string +--rw description? string
+--rw interface-id? string +--rw interface-id? string
+--rw active-vpn-node-profile? leafref +--rw active-vpn-node-profile? leafref
+--rw status +--rw status
| ... | ...
+--rw connection +--rw connection
| ... | ...
+--rw (signaling-option)? +--rw (signaling-option)?
| +--:(bgp) | +--:(bgp)
| +--rw (bgp-type)? | +--rw (bgp-type)?
| +--:(l2vpn-bgp) | +--:(l2vpn-bgp)
| | +--rw ce-id? uint16 | | +--rw ce-id? uint16
| | +--rw remote-ce-id? uint16 | | +--rw remote-ce-id? uint16
| | +--rw vpls-instance | | +--rw vpls-instance
| | +--rw vpls-edge-id? uint16 | | +--rw vpls-edge-id? uint16
| +--:(evpn-bgp) | +--:(evpn-bgp)
| +--rw df-preference? uint16 | +--rw df-preference? uint16
| +--rw vpws-service-instance | +--rw vpws-service-instance
| ... | ...
+--rw group* [group-id] +--rw group* [group-id]
| +--rw group-id string | +--rw group-id string
| +--rw precedence? identityref | +--rw precedence? identityref
| +--rw ethernet-segment-identifier? | +--rw ethernet-segment-identifier?
| l2vpn-es:es-ref | l2vpn-es:es-ref
+--rw ethernet-service-oam +--rw ethernet-service-oam
| ... | ...
+--rw service +--rw service
... ...
Figure 14: VPN Network Access Subtree Figure 14: VPN Network Access Subtree
The VPN network access comprises: The VPN network access is comprised of the following:
'id': Includes an identifier of the VPN network access. 'id': Includes an identifier of the VPN network access.
'description': Includes a textual description of the VPN network 'description': Includes a textual description of the VPN network
access. access.
'interface-id': Indicates the interface on which the VPN network 'interface-id': Indicates the interface on which the VPN network
access is bound. access is bound.
'active-vpn-node-profile': Provides a pointer to an active 'global- 'active-vpn-node-profile': Provides a pointer to an active 'global-
skipping to change at page 36, line 17 skipping to change at line 1504
'global-parameters-profile' implies that all associated data nodes 'global-parameters-profile' implies that all associated data nodes
will be inherited by the VPN network access. However, some of the will be inherited by the VPN network access. However, some of the
inherited data nodes (e.g., ACL policies) can be overridden at the inherited data nodes (e.g., ACL policies) can be overridden at the
VPN network access level. In such case, adjusted values take VPN network access level. In such case, adjusted values take
precedence over inherited values. precedence over inherited values.
'status': Indicates the administrative and operational status of the 'status': Indicates the administrative and operational status of the
VPN network access. VPN network access.
'connection': Represents and groups the set of Layer 2 connectivity 'connection': Represents and groups the set of Layer 2 connectivity
from where the traffic of the L2VPN in a particular VPN Network from where the traffic of the L2VPN in a particular VPN network
access is coming. See Section 7.6.1. access is coming. See Section 7.6.1.
'signaling-option': Indicates a set of signaling options that are 'signaling-option': Indicates a set of signaling options that are
specific to a given VPN network access, e.g., a CE ID ('ce-id' specific to a given VPN network access, e.g., a CE ID ('ce-id'
identifying the CE within the VPN) and a remote CE ID as discussed identifying the CE within the VPN) and a remote CE ID as discussed
in Section 2.2.2 of [RFC6624]. in Section 2.2.2 of [RFC6624].
It can also include a set of data nodes that are required for the It can also include a set of data nodes that are required for the
configuration of a VPWS-EVPN [RFC8214]. See Section 7.6.2. configuration of a VPWS-EVPN [RFC8214]. See Section 7.6.2.
skipping to change at page 36, line 40 skipping to change at line 1527
used to differentiate the primary and secondary accesses for a used to differentiate the primary and secondary accesses for a
service with multiple accesses. An example to illustrate the use service with multiple accesses. An example to illustrate the use
of this container for redundancy purposes is provided in of this container for redundancy purposes is provided in
Appendix A.6. This container is also used to identify the link of Appendix A.6. This container is also used to identify the link of
an ES by allocating the same ESI. An example to illustrate this an ES by allocating the same ESI. An example to illustrate this
functionality is provided in Appendices A.4 and A.5. functionality is provided in Appendices A.4 and A.5.
'ethernet-service-oam': Carries information about the service OAM. 'ethernet-service-oam': Carries information about the service OAM.
See Section 7.6.3. See Section 7.6.3.
'service': Specifies the service parameters (e.g., QoS, multicast) 'service': Specifies the service parameters (e.g., QoS and
to apply for a given VPN network access. See Section 7.6.4. multicast) to apply for a given VPN network access. See
Section 7.6.4.
7.6.1. Connection 7.6.1. Connection
The 'connection' container (Figure 15) is used to configure the The 'connection' container (Figure 15) is used to configure the
relevant properties of the interface to which the L2VPN instance is relevant properties of the interface to which the L2VPN instance is
attached to (e.g., encapsulation type, Link Aggregation Group (LAG) attached to (e.g., encapsulation type, Link Aggregation Group (LAG)
interfaces, split-horizon). The L2NM supports tag manipulation interfaces, and split-horizon). The L2NM supports tag manipulation
operations (e.g., tag rewrite). operations (e.g., tag rewrite).
Note that the 'connection' container does not include the physical- Note that the 'connection' container does not include the physical-
specific configuration as this is assumed to be directly handled specific configuration as this is assumed to be directly handled
using device modules (e.g., interfaces module). Moreover, this using device modules (e.g., an interfaces module). Moreover, this
design is also meant to avoid manipulated global parameters at the design is also meant to avoid manipulated global parameters at the
service level and lower the risk of impacting other services sharing service level and lower the risk of impacting other services sharing
the same physical interface. the same physical interface.
A reference to the bearer is maintained to allow keeping the link A reference to the bearer is maintained to allow keeping the link
between the L2SM and the L2NM when both data models are used in a between the L2SM and the L2NM when both data models are used in a
given deployment. given deployment.
Some consistency checks should be ensured by implementations Some consistency checks should be ensured by implementations
(typically, network controllers) for LAG interface as the same (typically, network controllers) for LAG interfaces, as the same
information (e.g., LACP system-id) should be provided to the involved information (e.g., LACP system-id) should be provided to the involved
nodes. nodes.
The L2NM inherits the 'member-link-list' structure from the L2SM The L2NM inherits the 'member-link-list' structure from the L2SM
(including indication of OAM 802.3ah support [IEEE-802-3ah]). (including indication of OAM 802.3ah support [IEEE-802-3ah]).
... ...
+--rw vpn-nodes +--rw vpn-nodes
+--rw vpn-node* [vpn-node-id] +--rw vpn-node* [vpn-node-id]
... ...
skipping to change at page 41, line 12 skipping to change at line 1709
Figure 16: EVPN-VPWS Service Instance Subtree Figure 16: EVPN-VPWS Service Instance Subtree
7.6.3. Ethernet OAM 7.6.3. Ethernet OAM
Ethernet OAM refers to both [IEEE-802-1ag] and [ITU-T-Y-1731]. 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 As shown in Figure 17, the L2NM inherits the same structure as in
Section 5.3.2.2.6 of [RFC8466] for OAM matters. Section 5.3.2.2.6 of [RFC8466] for OAM matters.
+--rw l2vpn-ntw +--rw l2vpn-ntw
+--rw vpn-profiles +--rw vpn-profiles
| ... | ...
+--rw vpn-services +--rw vpn-services
+--rw vpn-service* [vpn-id] +--rw vpn-service* [vpn-id]
... ...
+--rw vpn-nodes +--rw vpn-nodes
+--rw vpn-node* [vpn-node-id] +--rw vpn-node* [vpn-node-id]
... ...
+--rw vpn-network-accesses +--rw vpn-network-accesses
+--rw vpn-network-access* [id] +--rw vpn-network-access* [id]
... ...
+--rw ethernet-service-oam +--rw ethernet-service-oam
| +--rw md-name? string | +--rw md-name? string
| +--rw md-level? uint8 | +--rw md-level? uint8
| +--rw cfm-802.1-ag | +--rw cfm-802.1-ag
| | +--rw n2-uni-c* [maid] | | +--rw n2-uni-c* [maid]
| | | +--rw maid string | | | +--rw maid string
| | | +--rw mep-id? uint32 | | | +--rw mep-id? uint32
| | | +--rw mep-level? uint32 | | | +--rw mep-level? uint32
| | | +--rw mep-up-down? | | | +--rw mep-up-down?
| | | | enumeration | | | | enumeration
| | | +--rw remote-mep-id? uint32 | | | +--rw remote-mep-id? uint32
| | | +--rw cos-for-cfm-pdus? uint32 | | | +--rw cos-for-cfm-pdus? uint32
| | | +--rw ccm-interval? uint32 | | | +--rw ccm-interval? uint32
| | | +--rw ccm-holdtime? uint32 | | | +--rw ccm-holdtime? uint32
| | | +--rw ccm-p-bits-pri? | | | +--rw ccm-p-bits-pri?
| | | ccm-priority-type | | | ccm-priority-type
| | +--rw n2-uni-n* [maid] | | +--rw n2-uni-n* [maid]
| | +--rw maid string | | +--rw maid string
| | +--rw mep-id? uint32 | | +--rw mep-id? uint32
| | +--rw mep-level? uint32 | | +--rw mep-level? uint32
| | +--rw mep-up-down? | | +--rw mep-up-down?
| | | enumeration | | | enumeration
| | +--rw remote-mep-id? uint32 | | +--rw remote-mep-id? uint32
| | +--rw cos-for-cfm-pdus? uint32 | | +--rw cos-for-cfm-pdus? uint32
| | +--rw ccm-interval? uint32 | | +--rw ccm-interval? uint32
| | +--rw ccm-holdtime? uint32 | | +--rw ccm-holdtime? uint32
| | +--rw ccm-p-bits-pri? | | +--rw ccm-p-bits-pri?
| | ccm-priority-type | | ccm-priority-type
| +--rw y-1731* [maid] | +--rw y-1731* [maid]
| +--rw maid string | +--rw maid string
| +--rw mep-id? uint32 | +--rw mep-id? uint32
| +--rw pm-type? identityref | +--rw pm-type? identityref
| +--rw remote-mep-id? uint32 | +--rw remote-mep-id? uint32
| +--rw message-period? uint32 | +--rw message-period? uint32
| +--rw measurement-interval? uint32 | +--rw measurement-interval? uint32
| +--rw cos? uint32 | +--rw cos? uint32
| +--rw loss-measurement? boolean | +--rw loss-measurement? boolean
| +--rw synthethic-loss-measurement? | +--rw synthetic-loss-measurement?
| | boolean | | boolean
| +--rw delay-measurement | +--rw delay-measurement
| | +--rw enable-dm? boolean | | +--rw enable-dm? boolean
| | +--rw two-way? boolean | | +--rw two-way? boolean
| +--rw frame-size? uint32 | +--rw frame-size? uint32
| +--rw session-type? enumeration | +--rw session-type? enumeration
... ...
Figure 17: OAM Subtree Figure 17: OAM Subtree
7.6.4. Services 7.6.4. Services
The 'service' container (Figure 18) provides a set of service- The 'service' container (Figure 18) provides a set of service-
specific configuration such as Quality of Service (QoS). specific configurations such as QoS.
+--rw l2vpn-ntw +--rw l2vpn-ntw
+--rw vpn-profiles +--rw vpn-profiles
| ... | ...
+--rw vpn-services +--rw vpn-services
+--rw vpn-service* [vpn-id] +--rw vpn-service* [vpn-id]
... ...
+--rw vpn-nodes +--rw vpn-nodes
+--rw vpn-node* [vpn-node-id] +--rw vpn-node* [vpn-node-id]
... ...
+--rw vpn-network-accesses +--rw vpn-network-accesses
+--rw vpn-network-access* [id] +--rw vpn-network-access* [id]
... ...
+--rw service +--rw service
+--rw mtu? uint32 +--rw mtu? uint32
+--rw svc-pe-to-ce-bandwidth +--rw svc-pe-to-ce-bandwidth
| {vpn-common:inbound-bw}? | {vpn-common:inbound-bw}?
| ... | ...
+--rw svc-ce-to-pe-bandwidth +--rw svc-ce-to-pe-bandwidth
| {vpn-common:outbound-bw}? | {vpn-common:outbound-bw}?
| ... | ...
+--rw qos {vpn-common:qos}? +--rw qos {vpn-common:qos}?
| ... | ...
+--rw mac-policies +--rw mac-policies
| ... | ...
+--rw broadcast-unknown-unicast-multicast +--rw broadcast-unknown-unicast-multicast
... ...
Figure 18: Service Overall Subtree Figure 18: Service Overall Subtree
The description of the service data nodes is as follows: The description of the service data nodes is as follows:
'mtu': Specifies the Layer 2 MTU, in bytes, for the VPN network 'mtu': Specifies the Layer 2 MTU, in bytes, for the VPN network
access. access.
'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth': Specify the 'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth': Specify the
service bandwidth for the L2VPN service. service bandwidth for the L2VPN service.
skipping to change at page 44, line 9 skipping to change at line 1827
provider). provider).
'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth' can be 'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth' can be
represented using the Committed Information Rate (CIR), the Excess represented using the Committed Information Rate (CIR), the Excess
Information Rate (EIR), or the Peak Information Rate (PIR). Information Rate (EIR), or the Peak Information Rate (PIR).
As shown in Figure 19, the structure of service bandwidth data As shown in Figure 19, the structure of service bandwidth data
nodes is inherited from the L2SM [RFC8466]. The following types, nodes is inherited from the L2SM [RFC8466]. The following types,
defined in [RFC9181], can be used to indicate the bandwidth type: defined in [RFC9181], can be used to indicate the bandwidth type:
'bw-per-cos': The bandwidth is per Class of Service (CoS). 'bw-per-cos': The bandwidth is per CoS.
'bw-per-port': The bandwidth is per VPN network access. 'bw-per-port': The bandwidth is per VPN network access.
'bw-per-site': The bandwidth is to all VPN network accesses that 'bw-per-site': The bandwidth is to all VPN network accesses that
belong to the same site. belong to the same site.
'bw-per-service': The bandwidth is per L2VPN service. 'bw-per-service': The bandwidth is per L2VPN service.
+--rw service +--rw service
... ...
+--rw svc-pe-to-ce-bandwidth +--rw svc-pe-to-ce-bandwidth
| {vpn-common:inbound-bw}? | {vpn-common:inbound-bw}?
| +--rw pe-to-ce-bandwidth* [bw-type] | +--rw pe-to-ce-bandwidth* [bw-type]
| +--rw bw-type identityref | +--rw bw-type identityref
| +--rw (type)? | +--rw (type)?
| +--:(per-cos) | +--:(per-cos)
| | +--rw cos* [cos-id] | | +--rw cos* [cos-id]
| | +--rw cos-id uint8 | | +--rw cos-id uint8
| | +--rw cir? uint64 | | +--rw cir? uint64
| | +--rw cbs? uint64 | | +--rw cbs? uint64
| | +--rw eir? uint64 | | +--rw eir? uint64
| | +--rw ebs? uint64 | | +--rw ebs? uint64
| | +--rw pir? uint64 | | +--rw pir? uint64
| | +--rw pbs? uint64 | | +--rw pbs? uint64
| +--:(other) | +--:(other)
| +--rw cir? uint64 | +--rw cir? uint64
| +--rw cbs? uint64 | +--rw cbs? uint64
| +--rw eir? uint64 | +--rw eir? uint64
| +--rw ebs? uint64 | +--rw ebs? uint64
| +--rw pir? uint64 | +--rw pir? uint64
| +--rw pbs? uint64 | +--rw pbs? uint64
+--rw svc-ce-to-pe-bandwidth +--rw svc-ce-to-pe-bandwidth
| {vpn-common:outbound-bw}? | {vpn-common:outbound-bw}?
| +--rw ce-to-pe-bandwidth* [bw-type] | +--rw ce-to-pe-bandwidth* [bw-type]
| +--rw bw-type identityref | +--rw bw-type identityref
| +--rw (type)? | +--rw (type)?
| +--:(per-cos) | +--:(per-cos)
| | +--rw cos* [cos-id] | | +--rw cos* [cos-id]
| | +--rw cos-id uint8 | | +--rw cos-id uint8
| | +--rw cir? uint64 | | +--rw cir? uint64
| | +--rw cbs? uint64 | | +--rw cbs? uint64
| | +--rw eir? uint64 | | +--rw eir? uint64
| | +--rw ebs? uint64 | | +--rw ebs? uint64
| | +--rw pir? uint64 | | +--rw pir? uint64
| | +--rw pbs? uint64 | | +--rw pbs? uint64
| +--:(other) | +--:(other)
| +--rw cir? uint64 | +--rw cir? uint64
| +--rw cbs? uint64 | +--rw cbs? uint64
| +--rw eir? uint64 | +--rw eir? uint64
| +--rw ebs? uint64 | +--rw ebs? uint64
| +--rw pir? uint64 | +--rw pir? uint64
| +--rw pbs? uint64 | +--rw pbs? uint64
... ...
Figure 19: Service Bandwidth Subtree Figure 19: Service Bandwidth Subtree
'qos': Is used to define a set of QoS policies to apply on a given 'qos': Is used to define a set of QoS policies to apply on a given
VPN network access (Figure 20). The QoS classification can be VPN network access (Figure 20). The QoS classification can be
based on many criteria such as source MAC address, destination MAC based on many criteria such as source MAC address, destination MAC
address, etc. See also Section 5.10.2.1 of [RFC8466] for more address, etc. See also Section 5.10.2.1 of [RFC8466] for more
discussion of QoS classification including the use of color types. discussion of QoS classification including the use of color types.
+--rw service +--rw service
... ...
+--rw qos {vpn-common:qos}? +--rw qos {vpn-common:qos}?
| +--rw qos-classification-policy | +--rw qos-classification-policy
| | +--rw rule* [id] | | +--rw rule* [id]
| | +--rw id string | | +--rw id string
| | +--rw (match-type)? | | +--rw (match-type)?
| | | +--:(match-flow) | | | +--:(match-flow)
| | | | +--rw match-flow | | | | +--rw match-flow
skipping to change at page 46, line 40 skipping to change at line 1919
| | | +--:(match-application) | | | +--:(match-application)
| | | +--rw match-application? | | | +--rw match-application?
| | | identityref | | | identityref
| | +--rw target-class-id? string | | +--rw target-class-id? string
| +--rw qos-profile | +--rw qos-profile
| +--rw qos-profile* [profile] | +--rw qos-profile* [profile]
| +--rw profile leafref | +--rw profile leafref
| +--rw direction? identityref | +--rw direction? identityref
... ...
Figure 20: QoS Subtree Figure 20: QoS Subtree
'mac-policies': Lists a set of MAC-related policies such as MAC 'mac-policies': Lists a set of MAC-related policies such as MAC
ACLs. Similar to [RFC8519], an ACL match can be based upon source ACLs. Similar to [RFC8519], an ACL match can be based upon source
MAC address, source MAC address mask, destination MAC address, MAC address, source MAC address mask, destination MAC address,
destination MAC address mask, or a combination thereof. destination MAC address mask, or a combination thereof.
A data frame that matches an ACL can be dropped, flooded, or A data frame that matches an ACL can be dropped, be flooded, or
trigger an alarm. A rate-limit policy can be defined for handling trigger an alarm. A rate-limit policy can be defined for handling
frames that match an ACL entry with 'flood' action. frames that match an ACL entry with 'flood' action.
When 'mac-loop-prevention' or 'mac-addr-limit' data nodes are When 'mac-loop-prevention' or 'mac-addr-limit' data nodes are
provided, they take precedence over the ones inlcuded in the provided, they take precedence over the ones included in the
'global-parameters-profile' at the VPN service or VPN node levels. 'global-parameters-profile' at the VPN service or VPN node levels.
+--rw service +--rw service
... ...
+--rw mac-policies +--rw mac-policies
| +--rw access-control-list* [name] | +--rw access-control-list* [name]
| | +--rw name string | | +--rw name string
| | +--rw src-mac-address* | | +--rw src-mac-address*
| | | yang:mac-address | | | yang:mac-address
| | +--rw src-mac-address-mask* | | +--rw src-mac-address-mask*
| | | yang:mac-address | | | yang:mac-address
| | +--rw dst-mac-address* | | +--rw dst-mac-address*
| | | yang:mac-address | | | yang:mac-address
| | +--rw dst-mac-address-mask* | | +--rw dst-mac-address-mask*
| | | yang:mac-address | | | yang:mac-address
| | +--rw action? identityref | | +--rw action? identityref
| | +--rw rate-limit? decimal64 | | +--rw rate-limit? decimal64
| +--rw mac-loop-prevention | +--rw mac-loop-prevention
| | +--rw window? uint32 | | +--rw window? uint32
| | +--rw frequency? uint32 | | +--rw frequency? uint32
| | +--rw retry-timer? uint32 | | +--rw retry-timer? uint32
| | +--rw protection-type? identityref | | +--rw protection-type? identityref
| +--rw mac-addr-limit | +--rw mac-addr-limit
| +--rw limit-number? uint16 | +--rw limit-number? uint16
| +--rw time-interval? uint32 | +--rw time-interval? uint32
| +--rw action? identityref | +--rw action? identityref
... ...
Figure 21: MAC Policies Subtree Figure 21: MAC Policies Subtree
'broadcast-unknown-unicast-multicast': Defines the type of site in 'broadcast-unknown-unicast-multicast': Defines the type of site in
the customer multicast service topology: source, receiver, or the customer multicast service topology: source, receiver, or
both. It is also used to define multicast group-to-port mappings. both. It is also used to define multicast group-to-port mappings.
+--rw service +--rw service
... ...
+--rw broadcast-unknown-unicast-multicast +--rw broadcast-unknown-unicast-multicast
+--rw multicast-site-type? +--rw multicast-site-type?
| enumeration | enumeration
+--rw multicast-gp-address-mapping* [id] +--rw multicast-gp-address-mapping* [id]
| +--rw id uint16 | +--rw id uint16
| +--rw vlan-id uint32 | +--rw vlan-id uint32
| +--rw mac-gp-address | +--rw mac-gp-address
| | yang:mac-address | | yang:mac-address
| +--rw port-lag-number? uint32 | +--rw port-lag-number? uint32
+--rw bum-overall-rate? uint64 +--rw bum-overall-rate? uint64
Figure 22: BUM Subtree Figure 22: BUM Subtree
8. YANG Modules 8. YANG Modules
8.1. IANA-Maintained Module for BGP Layer 2 Encapsulation Types 8.1. IANA-Maintained Module for BGP Layer 2 Encapsulation Types
The "iana-bgp-l2-encaps" YANG module echoes the registry available at The "iana-bgp-l2-encaps" YANG module matches the "BGP Layer 2
[IANA-BGP-L2]. Encapsulation Types" registry [IANA-BGP-L2].
This module references [RFC3032], [RFC4446], [RFC4448], [RFC4553], This module references [RFC3032], [RFC4446], [RFC4448], [RFC4553],
[RFC4618], [RFC4619], [RFC4717], [RFC4761], [RFC4816], [RFC4842], and [RFC4618], [RFC4619], [RFC4717], [RFC4761], [RFC4816], [RFC4842], and
[RFC5086]. [RFC5086].
<CODE BEGINS> <CODE BEGINS> file "iana-bgp-l2-encaps@2022-09-20.yang"
file "iana-bgp-l2-encaps@2021-07-05.yang"
module iana-bgp-l2-encaps { module iana-bgp-l2-encaps {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps"; namespace "urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps";
prefix iana-bgp-l2-encaps; prefix iana-bgp-l2-encaps;
organization organization
"IANA"; "IANA";
contact contact
"Internet Assigned Numbers Authority "Internet Assigned Numbers Authority
Postal: ICANN Postal: ICANN
12025 Waterfront Drive, Suite 300 12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536 Los Angeles, CA 90094-2536
United States of America United States of America
Tel: +1 310 301 5800 Tel: +1 310 301 5800
<mailto:iana@iana.org>"; <mailto:iana@iana.org>";
description description
"This module contains a collection of IANA-maintained YANG "This YANG module contains a collection of IANA-maintained YANG
data types that are used for referring to BGP Layer 2 data types that are used for referring to BGP Layer 2
encapsulation types. encapsulation types.
Copyright (c) 2022 IETF Trust and the persons identified as Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 9291; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2021-07-05 { revision 2022-09-20 {
description description
"First revision."; "First revision.";
reference reference
"RFC XXXX: A YANG Network Data Model for Layer 2 VPNs."; "RFC 9291: A YANG Network Data Model for Layer 2 VPNs.";
} }
identity bgp-l2-encaps-type { identity bgp-l2-encaps-type {
description description
"Base BGP Layer 2 encapsulation type."; "Base BGP Layer 2 encapsulation type.";
reference reference
"RFC 6624: Layer 2 Virtual Private Networks Using BGP for "RFC 6624: Layer 2 Virtual Private Networks Using BGP for
Auto-Discovery and Signaling"; Auto-Discovery and Signaling";
} }
skipping to change at page 54, line 7 skipping to change at line 2264
reference reference
"RFC 5086: Structure-Aware Time Division Multiplexed (TDM) "RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over Packet Switched Circuit Emulation Service over Packet Switched
Network (CESoPSN)"; Network (CESoPSN)";
} }
} }
<CODE ENDS> <CODE ENDS>
8.2. IANA-Maintained Module for Pseudowire Types 8.2. IANA-Maintained Module for Pseudowire Types
The initial version of the "iana-pseudowire-types" YANG module echoes The initial version of the "iana-pseudowire-types" YANG module
the registry available at [IANA-PW-Types]. matches the "MPLS Pseudowire Types Registry" [IANA-PW-TYPES].
This module references [MFA], [RFC2507], [RFC2508], [RFC3032], This module references [MFA], [RFC2507], [RFC2508], [RFC3032],
[RFC3545], [RFC4448], [RFC4618], [RFC4619], [RFC4717], [RFC4842], [RFC3545], [RFC4448], [RFC4553], [RFC4618], [RFC4619], [RFC4717],
[RFC4863], [RFC4901], [RFC5086], [RFC5087], [RFC5143], [RFC5795], and [RFC4842], [RFC4863], [RFC4901], [RFC5086], [RFC5087], [RFC5143],
[RFC6307]. [RFC5795], and [RFC6307].
<CODE BEGINS> <CODE BEGINS> file "iana-pseudowire-types@2022-09-20.yang"
file "iana-pseudowire-types@2021-07-05.yang"
module iana-pseudowire-types { module iana-pseudowire-types {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:iana-pseudowire-types"; namespace "urn:ietf:params:xml:ns:yang:iana-pseudowire-types";
prefix iana-pw-types; prefix iana-pw-types;
organization organization
"IANA"; "IANA";
contact contact
"Internet Assigned Numbers Authority "Internet Assigned Numbers Authority
skipping to change at page 54, line 47 skipping to change at line 2303
Copyright (c) 2022 IETF Trust and the persons identified as Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 9291; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2021-07-05 { revision 2022-09-20 {
description description
"First revision."; "First revision.";
reference reference
"RFC XXXX: A YANG Network Data Model for Layer 2 VPNs."; "RFC RFC 9291: A YANG Network Data Model for Layer 2 VPNs.";
} }
identity iana-pw-types { identity iana-pw-types {
description description
"Base Pseudowire Layer 2 encapsulation type."; "Base Pseudowire Layer 2 encapsulation type.";
} }
identity frame-relay { identity frame-relay {
base iana-pw-types; base iana-pw-types;
description description
skipping to change at page 61, line 37 skipping to change at line 2631
"RFC 4863: Wildcard Pseudowire Type"; "RFC 4863: Wildcard Pseudowire Type";
} }
} }
<CODE ENDS> <CODE ENDS>
8.3. Ethernet Segments 8.3. Ethernet Segments
The "ietf-ethernet-segment" YANG module uses types defined in The "ietf-ethernet-segment" YANG module uses types defined in
[RFC6991]. [RFC6991].
<CODE BEGINS> <CODE BEGINS> file "ietf-ethernet-segment@2022-09-20.yang"
file "ietf-ethernet-segment@2022-05-25.yang"
module ietf-ethernet-segment { module ietf-ethernet-segment {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ethernet-segment"; namespace "urn:ietf:params:xml:ns:yang:ietf-ethernet-segment";
prefix l2vpn-es; prefix l2vpn-es;
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference reference
"RFC 6991: Common YANG Data Types, Section 3"; "RFC 6991: Common YANG Data Types (see Section 3)";
} }
organization organization
"IETF OPSA (Operations and Management Area) Working Group"; "IETF OPSA (Operations and Management Area) Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/> "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org> WG List: <mailto:opsawg@ietf.org>
Editor: Mohamed Boucadair Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>
Editor: Samier Barguil Editor: Samier Barguil
<mailto:samier.barguilgiraldo.ext@telefonica.com> <mailto:samier.barguilgiraldo.ext@telefonica.com>
Author: Oscar Gonzalez de Dios Author: Oscar Gonzalez de Dios
<mailto:oscar.gonzalezdedios@telefonica.com>"; <mailto:oscar.gonzalezdedios@telefonica.com>";
description description
"This YANG module defines a model for Ethernet Segments. "This YANG module defines a model for Ethernet Segments.
Copyright (c) 2021 IETF Trust and the persons identified as Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 9291; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2022-05-25 { revision 2022-09-20 {
description description
"Initial version."; "Initial version.";
reference reference
"RFC XXXX: A YANG Network Data Model for Layer 2 VPNs."; "RFC 9291: A YANG Network Data Model for Layer 2 VPNs.";
} }
/* Typedefs */ /* Typedefs */
typedef es-ref { typedef es-ref {
type leafref { type leafref {
path "/l2vpn-es:ethernet-segments/l2vpn-es:ethernet-segment" path "/l2vpn-es:ethernet-segments/l2vpn-es:ethernet-segment"
+ "/l2vpn-es:name"; + "/l2vpn-es:name";
} }
description description
"Defines a type for referencing an Ethernet segment in "Defines a type for referencing an Ethernet segment in
other modules."; other modules.";
} }
/* Identities */ /* Identities */
identity esi-type { identity esi-type {
description description
"T-(Ethernet Segment Identifier (ESI) Type) is a 1-octet field "T (Ethernet Segment Identifier (ESI) Type) is a 1-octet field
(most significant octet) that specifies the format of the (most significant octet) that specifies the format of the
remaining 9 octets (ESI Value)."; remaining 9 octets (ESI Value).";
reference reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 5"; "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 5";
} }
identity esi-type-0-operator { identity esi-type-0-operator {
base esi-type; base esi-type;
description description
"This type indicates an arbitrary 9-octet ESI value, "This type indicates an arbitrary 9-octet ESI value,
which is managed and configured by the operator."; which is managed and configured by the operator.";
} }
identity esi-type-1-lacp { identity esi-type-1-lacp {
base esi-type; base esi-type;
description description
"When IEEE 802.1AX Link Aggregation Control Protocol (LACP) "When the IEEE 802.1AX Link Aggregation Control Protocol (LACP)
is used between the Provider Edge (PE) and Customer Edge (CE) is used between the Provider Edge (PE) and Customer Edge (CE)
devices, this ESI type indicates an auto-generated ESI value devices, this ESI type indicates an auto-generated ESI value
determined from LACP."; determined from LACP.";
reference reference
"IEEE Std. 802.1AX: Link Aggregation"; "IEEE Std 802.1AX: Link Aggregation";
} }
identity esi-type-2-bridge { identity esi-type-2-bridge {
base esi-type; base esi-type;
description description
"The ESI value is auto-generated and determined based "The ESI value is auto-generated and determined based
on the Layer 2 bridge protocol."; on the Layer 2 bridge protocol.";
} }
identity esi-type-3-mac { identity esi-type-3-mac {
skipping to change at page 64, line 40 skipping to change at line 2780
description description
"The highest random weight (HRW) method."; "The highest random weight (HRW) method.";
reference reference
"RFC 8584: Framework for Ethernet VPN Designated "RFC 8584: Framework for Ethernet VPN Designated
Forwarder Election Extensibility, Section 3"; Forwarder Election Extensibility, Section 3";
} }
identity preference { identity preference {
base df-election-methods; base df-election-methods;
description description
"The preference based method. PEs are assigned with "The preference-based method. PEs are assigned with
preferences to become the DF in the Ethernet Segment (ES). preferences to become the DF in the Ethernet Segment (ES).
The exact preference-based algorithm (e.g., lowest-preference The exact preference-based algorithm (e.g., lowest-preference
algorithm, highest-preference algorithm) to use is algorithm or highest-preference algorithm) to use is
signaled at the control plane."; signaled at the control plane.";
} }
identity es-redundancy-mode { identity es-redundancy-mode {
description description
"Base identity for ES redundancy modes."; "Base identity for ES redundancy modes.";
} }
identity single-active { identity single-active {
base es-redundancy-mode; base es-redundancy-mode;
description description
"Indicates Single-Active redundancy mode for a given ES."; "Indicates Single-Active redundancy mode for a given ES.";
reference reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 14.1.1"; "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 14.1.1";
} }
identity all-active { identity all-active {
base es-redundancy-mode; base es-redundancy-mode;
skipping to change at page 66, line 32 skipping to change at line 2867
} }
} }
case auto-assigned { case auto-assigned {
description description
"The ESI is auto-assigned."; "The ESI is auto-assigned.";
container esi-auto { container esi-auto {
description description
"The ESI is auto-assigned."; "The ESI is auto-assigned.";
choice auto-mode { choice auto-mode {
description description
"Indicates the auto-assignment mode. ESI can be "Indicates the auto-assignment mode. ESI can be
automatically assigned either with or without automatically assigned either with or without
indicating a pool from which the ESI should be indicating a pool from which the ESI should be
taken. taken.
For both cases, the server will auto-assign an For both cases, the server will auto-assign an
ESI value 'auto-assigned-ESI' and use that value ESI value 'auto-assigned-ESI' and use that value
operationally."; operationally.";
case from-pool { case from-pool {
leaf esi-pool-name { leaf esi-pool-name {
type string; type string;
skipping to change at page 68, line 5 skipping to change at line 2937
+ "'preference')" { + "'preference')" {
description description
"The revertive value is only applicable "The revertive value is only applicable
to the preference method."; to the preference method.";
} }
type boolean; type boolean;
default "true"; default "true";
description description
"The default behavior is that the DF election "The default behavior is that the DF election
procedure is triggered upon PE failures following procedure is triggered upon PE failures following
configured preference values. Such a mode is called configured preference values. Such a mode is called
the revertive mode. This mode may not be suitable in the 'revertive' mode. This mode may not be suitable in
some scenarios where, e.g., an operator may want to some scenarios where, e.g., an operator may want to
maintain the new DF even if the former DF recovers. maintain the new DF even if the former DF recovers.
Such a mode is called the 'non-revertive' mode. Such a mode is called the 'non-revertive' mode.
The non-revertive mode can be configured by The non-revertive mode can be configured by
setting 'revertive' leaf to 'false'."; setting 'revertive' leaf to 'false'.";
reference reference
"RFC 8584: Framework for Ethernet VPN Designated "RFC 8584: Framework for Ethernet VPN Designated
Forwarder Election Extensibility, Forwarder Election Extensibility,
Section 1.3.2"; Section 1.3.2";
} }
leaf election-wait-time { leaf election-wait-time {
type uint32; type uint32;
units "seconds"; units "seconds";
default "3"; default "3";
description description
"Election wait timer."; "Designated Forwarder Wait timer.";
reference reference
"RFC 8584: Framework for Ethernet VPN Designated "RFC 8584: Framework for Ethernet VPN Designated
Forwarder Election Extensibility"; Forwarder Election Extensibility";
} }
} }
leaf split-horizon-filtering { leaf split-horizon-filtering {
type boolean; type boolean;
description description
"Controls split-horizon filtering. It is enabled "Controls split-horizon filtering. It is enabled
when set to 'true'. when set to 'true'.
In order to achieve split-horizon filtering, every In order to achieve split-horizon filtering, every
Broadcast, unknown unicast, or multicast (BUM) Broadcast, Unknown Unicast, or Multicast (BUM)
packet originating from a non-DF PE is encapsulated packet originating from a non-DF PE is encapsulated
with an MPLS label that identifies the origin ES."; with an MPLS label that identifies the origin ES.";
reference reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 8.3"; "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 8.3";
} }
container pbb { container pbb {
description description
"Provider Backbone Bridging (PBB) parameters ."; "Provider Backbone Bridging (PBB) parameters .";
reference reference
"IEEE 802.1ah: Provider Backbone Bridge"; "IEEE 802.1ah: Provider Backbone Bridges";
leaf backbone-src-mac { leaf backbone-src-mac {
type yang:mac-address; type yang:mac-address;
description description
"The PEs connected to the same CE must share the "The PEs connected to the same CE must share the
same Provider Backbone (B-MAC) address in same Provider Backbone (B-MAC) address in
All-Active mode."; All-Active mode.";
reference reference
"RFC 7623: Provider Backbone Bridging Combined with "RFC 7623: Provider Backbone Bridging Combined with
Ethernet VPN (PBB-EVPN), Section 6.2.1.1"; Ethernet VPN (PBB-EVPN), Section 6.2.1.1";
} }
skipping to change at page 69, line 34 skipping to change at line 3014
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
8.4. L2NM 8.4. L2NM
The "ietf-l2vpn-ntw" YANG module uses types defined in [RFC6991], The "ietf-l2vpn-ntw" YANG module uses types defined in [RFC6991],
[RFC9181], [RFC8294], and [IEEE802.1Qcp-2018]. [RFC9181], [RFC8294], and [IEEE802.1Qcp].
<CODE BEGINS> <CODE BEGINS> file "ietf-l2vpn-ntw@2022-09-20.yang"
file "ietf-l2vpn-ntw@2022-05-25.yang"
module ietf-l2vpn-ntw { module ietf-l2vpn-ntw {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw"; namespace "urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw";
prefix l2vpn-ntw; prefix l2vpn-ntw;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 6991: Common YANG Data Types, Section 4"; "RFC 6991: Common YANG Data Types, Section 4";
} }
skipping to change at page 70, line 4 skipping to change at line 3031
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 6991: Common YANG Data Types, Section 4"; "RFC 6991: Common YANG Data Types, Section 4";
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference reference
"RFC 6991: Common YANG Data Types, Section 3"; "RFC 6991: Common YANG Data Types, Section 3";
} }
import ietf-vpn-common { import ietf-vpn-common {
prefix vpn-common; prefix vpn-common;
reference reference
"RFC 9181: A Common YANG for Data Model for Layer 2 "RFC 9181: A Common YANG for Data Model for Layer 2
and Layer 3 VPNs"; and Layer 3 VPNs";
} }
import iana-bgp-l2-encaps { import iana-bgp-l2-encaps {
prefix iana-bgp-l2-encaps; prefix iana-bgp-l2-encaps;
reference reference
"RFC XXXX: A YANG Network Data Model for Layer 2 VPNs."; "RFC 9291: A YANG Network Data Model for Layer 2 VPNs.";
} }
import iana-pseudowire-types { import iana-pseudowire-types {
prefix iana-pw-types; prefix iana-pw-types;
reference reference
"RFC XXXX: A YANG Network Data Model for Layer 2 VPNs."; "RFC 9291: A YANG Network Data Model for Layer 2 VPNs.";
} }
import ietf-ethernet-segment { import ietf-ethernet-segment {
prefix l2vpn-es; prefix l2vpn-es;
reference reference
"RFC XXXX: A YANG Network Data Model for Layer 2 VPNs."; "RFC 9291: A YANG Network Data Model for Layer 2 VPNs.";
} }
import ietf-routing-types { import ietf-routing-types {
prefix rt-types; prefix rt-types;
reference reference
"RFC 8294: Common YANG Data Types for the Routing Area"; "RFC 8294: Common YANG Data Types for the Routing Area";
} }
import ieee802-dot1q-types { import ieee802-dot1q-types {
prefix dot1q-types; prefix dot1q-types;
reference reference
"IEEE Std 802.1Qcp-2018: Bridges and Bridged Networks - "IEEE Std 802.1Qcp: Bridges and Bridged Networks--
Amendment: YANG Data Model"; Amendment 30: YANG Data Model";
} }
organization organization
"IETF OPSA (Operations and Management Area) Working Group"; "IETF OPSA (Operations and Management Area) Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/> "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org> WG List: <mailto:opsawg@ietf.org>
Editor: Mohamed Boucadair Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>
skipping to change at page 70, line 47 skipping to change at line 3073
} }
organization organization
"IETF OPSA (Operations and Management Area) Working Group"; "IETF OPSA (Operations and Management Area) Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/> "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org> WG List: <mailto:opsawg@ietf.org>
Editor: Mohamed Boucadair Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>
Editor: Samier Barguil Editor: Samier Barguil
<mailto:samier.barguilgiraldo.ext@telefonica.com> <mailto:samier.barguilgiraldo.ext@telefonica.com>
Author: Oscar Gonzalez de Dios Author: Oscar Gonzalez de Dios
<mailto:oscar.gonzalezdedios@telefonica.com>"; <mailto:oscar.gonzalezdedios@telefonica.com>";
description description
"This YANG module defines a network model for Layer 2 VPN "This YANG module defines a network model for Layer 2 VPN
services. services.
Copyright (c) 2022 IETF Trust and the persons identified as Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 9291; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2022-05-25 { revision 2022-09-20 {
description description
"Initial version."; "Initial version.";
reference reference
"RFC XXXX: A YANG Network Data Model for Layer 2 VPNs."; "RFC 9291: A YANG Network Data Model for Layer 2 VPNs.";
} }
/* Features */ /* Features */
feature oam-3ah { feature oam-3ah {
description description
"Indicates the support of OAM 802.3ah."; "Indicates the support of OAM 802.3ah.";
reference reference
"IEEE Std 802.3ah: Media Access Control Parameters, Physical "IEEE Std 802.3ah: Media Access Control Parameters, Physical
Layers, and Management Parameters for Layers, and Management Parameters for
skipping to change at page 71, line 47 skipping to change at line 3125
/* Identities */ /* Identities */
identity evpn-service-interface-type { identity evpn-service-interface-type {
description description
"Base identity for EVPN service interface type."; "Base identity for EVPN service interface type.";
} }
identity vlan-based-service-interface { identity vlan-based-service-interface {
base evpn-service-interface-type; base evpn-service-interface-type;
description description
"VLAN-Based Service Interface."; "VLAN-based service interface.";
reference reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.1"; "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.1";
} }
identity vlan-bundle-service-interface { identity vlan-bundle-service-interface {
base evpn-service-interface-type; base evpn-service-interface-type;
description description
"VLAN Bundle Service Interface."; "VLAN bundle service interface.";
reference reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.2"; "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.2";
} }
identity vlan-aware-bundle-service-interface { identity vlan-aware-bundle-service-interface {
base evpn-service-interface-type; base evpn-service-interface-type;
description description
"VLAN-Aware Bundle Service Interface."; "VLAN-aware bundle service interface.";
reference reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.3"; "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.3";
} }
identity mapping-type { identity mapping-type {
base vpn-common:multicast-gp-address-mapping; base vpn-common:multicast-gp-address-mapping;
description description
"Identity for multicast group mapping type."; "Identity for multicast group mapping type.";
} }
skipping to change at page 72, line 45 skipping to change at line 3171
} }
identity trap { identity trap {
base loop-prevention-type; base loop-prevention-type;
description description
"Trap protection type."; "Trap protection type.";
} }
identity color-type { identity color-type {
description description
"Identity of color types. A type is assigned to a service frame "Identity of color types. A type is assigned to a service
to identify its QoS profile conformance."; frame to identify its QoS profile conformance.";
} }
identity green { identity green {
base color-type; base color-type;
description description
"'green' color type. A service frame is 'green' if it is "'green' color type. A service frame is 'green' if it is
conformant with the committed rate of the bandwidth profile."; conformant with the committed rate of the bandwidth profile.";
} }
identity yellow { identity yellow {
base color-type; base color-type;
description description
"'yellow' color type. A service frame is 'yellow' if it exceeds "'yellow' color type. A service frame is 'yellow' if it
the committed rate but is conformant with the excess rate exceeds the committed rate but is conformant with the excess
of the bandwidth profile."; rate of the bandwidth profile.";
} }
identity red { identity red {
base color-type; base color-type;
description description
"'red' color type. A service famre is 'red' if it is not "'red' color type. A service frame is 'red' if it is not
conformant with both the committed and excess rates of the conformant with both the committed and excess rates of the
bandwidth profile."; bandwidth profile.";
} }
identity t-ldp-pw-type { identity t-ldp-pw-type {
description description
"Identity for t-ldp-pw-type."; "Identity for T-LDP pseudowire (PW) type.";
} }
identity vpws-type { identity vpws-type {
base t-ldp-pw-type; base t-ldp-pw-type;
description description
"Virtual Private Wire Service (VPWS) t-ldp-pw-type."; "Virtual Private Wire Service (VPWS) t-ldp-pw-type.";
reference reference
"RFC 4664: Framework for Layer 2 Virtual Private Networks "RFC 4664: Framework for Layer 2 Virtual Private Networks
(L2VPNs), Section 3.3"; (L2VPNs), Section 3.3";
} }
skipping to change at page 74, line 32 skipping to change at line 3254
is initiated followed by an establishment of an is initiated followed by an establishment of an
Ethernet channel with the other end."; Ethernet channel with the other end.";
} }
identity lacp-passive { identity lacp-passive {
base lacp-mode; base lacp-mode;
description description
"LACP passive mode. "LACP passive mode.
This mode refers to the LACP mode where an endpoint does This mode refers to the LACP mode where an endpoint does
not initiate the negotiation, but only responds to LACP not initiate the negotiation but only responds to LACP
packets initiated by the other end (e.g., full duplex packets initiated by the other end (e.g., full duplex
or half duplex)"; or half duplex)";
} }
identity pm-type { identity pm-type {
description description
"Identity for performance monitoring type."; "Identity for performance monitoring type.";
} }
identity loss { identity loss {
skipping to change at page 75, line 49 skipping to change at line 3318
} }
identity warning { identity warning {
base mac-action; base mac-action;
description description
"Log a warning message as the MAC action."; "Log a warning message as the MAC action.";
} }
identity precedence-type { identity precedence-type {
description description
"Redundancy type. The service can be created "Redundancy type. The service can be created
with primary and secondary signalization."; with primary and secondary signalization.";
} }
identity primary { identity primary {
base precedence-type; base precedence-type;
description description
"Identifies the main VPN network access."; "Identifies the main VPN network access.";
} }
identity secondary { identity secondary {
base precedence-type; base precedence-type;
description description
"Identifies the secondary VPN network access."; "Identifies the secondary VPN network access.";
skipping to change at page 76, line 44 skipping to change at line 3362
"PW Ethernet tagged mode type."; "PW Ethernet tagged mode type.";
} }
/* Typedefs */ /* Typedefs */
typedef ccm-priority-type { typedef ccm-priority-type {
type uint8 { type uint8 {
range "0..7"; range "0..7";
} }
description description
"A 3-bit priority value to be used in the VLAN tag, "A 3-bit priority value to be used in the VLAN tag
if present in the transmitted frame. A larger value if present in the transmitted frame. A larger value
indicates a higher priority."; indicates a higher priority.";
} }
/* Groupings */ /* Groupings */
grouping cfm-802 { grouping cfm-802 {
description description
"Grouping for 802.1ag Connectivity Fault Management (CFM) "Grouping for 802.1ag Connectivity Fault Management (CFM)
attributes."; attributes.";
reference reference
"IEEE Std 802-1ag: Virtual Bridged Local Area Networks "IEEE Std 802.1ag: Virtual Bridged Local Area Networks
Amendment 5: Connectivity Fault Management"; Amendment 5: Connectivity Fault Management";
leaf maid { leaf maid {
type string; type string;
description description
"Maintenance Association Identifier (MAID)."; "Maintenance Association Identifier (MAID).";
} }
leaf mep-id { leaf mep-id {
type uint32; type uint32;
description description
"Local Maintenance Entity Group End Point (MEP) ID."; "Local Maintenance Entity Group End Point (MEP) ID.";
skipping to change at page 77, line 48 skipping to change at line 3414
"MEP up/down."; "MEP up/down.";
} }
leaf remote-mep-id { leaf remote-mep-id {
type uint32; type uint32;
description description
"Remote MEP ID."; "Remote MEP ID.";
} }
leaf cos-for-cfm-pdus { leaf cos-for-cfm-pdus {
type uint32; type uint32;
description description
"Class of service for CFM PDUs."; "Class of Service for CFM PDUs.";
} }
leaf ccm-interval { leaf ccm-interval {
type uint32; type uint32;
units "milliseconds"; units "milliseconds";
default "10000"; default "10000";
description description
"Continuity Check Message (CCM) interval."; "Continuity Check Message (CCM) interval.";
} }
leaf ccm-holdtime { leaf ccm-holdtime {
type uint32; type uint32;
units "milliseconds"; units "milliseconds";
default "35000"; default "35000";
description description
"CCM hold time."; "CCM hold time.";
} }
leaf ccm-p-bits-pri { leaf ccm-p-bits-pri {
type ccm-priority-type; type ccm-priority-type;
description description
"The priority parameter for Continuity Check Messages (CCMs) "The priority parameter for CCMs
transmitted by the MEP."; transmitted by the MEP.";
} }
} }
grouping y-1731 { grouping y-1731 {
description description
"Grouping for Y-1731"; "Grouping for Y-1731";
reference reference
"ITU-T Y-1731: Operations, administration and maintenance "ITU-T G.8013/Y.1731: Operations, administration and
(OAM) functions and mechanisms for maintenance (OAM) functions and
Ethernet-based networks"; mechanisms for Ethernet-based
networks";
list y-1731 { list y-1731 {
key "maid"; key "maid";
description description
"List of configured Y-1731 instances."; "List of configured Y-1731 instances.";
leaf maid { leaf maid {
type string; type string;
description description
"MAID."; "MAID.";
} }
leaf mep-id { leaf mep-id {
skipping to change at page 79, line 36 skipping to change at line 3498
description description
"Identifies the Class of Service."; "Identifies the Class of Service.";
} }
leaf loss-measurement { leaf loss-measurement {
type boolean; type boolean;
default "false"; default "false";
description description
"Controls whether loss measurement is ('true') or "Controls whether loss measurement is ('true') or
disabled ('false')."; disabled ('false').";
} }
leaf synthethic-loss-measurement { leaf synthetic-loss-measurement {
type boolean; type boolean;
default "false"; default "false";
description description
"Indicates whether synthetic loss measurement is enabled "Indicates whether synthetic loss measurement is
('true') or disabled ('false')."; enabled ('true') or disabled ('false').";
} }
container delay-measurement { container delay-measurement {
description description
"Container for delay measurement"; "Container for delay measurement.";
leaf enable-dm { leaf enable-dm {
type boolean; type boolean;
default "false"; default "false";
description description
"Controls whether delay measurement is enabled ('true') "Controls whether delay measurement is enabled
or disabled ('false')."; ('true') or disabled ('false').";
} }
leaf two-way { leaf two-way {
type boolean; type boolean;
default "false"; default "false";
description description
"Whether delay measurement is two-way ('true') of one- "Whether delay measurement is two-way ('true') of one-
way ('false')."; way ('false').";
} }
} }
leaf frame-size { leaf frame-size {
skipping to change at page 80, line 48 skipping to change at line 3559
"Container for per-service parameters."; "Container for per-service parameters.";
leaf local-autonomous-system { leaf local-autonomous-system {
type inet:as-number; type inet:as-number;
description description
"Indicates a local AS Number (ASN)."; "Indicates a local AS Number (ASN).";
} }
leaf svc-mtu { leaf svc-mtu {
type uint32; type uint32;
units "bytes"; units "bytes";
description description
"Layer 2 service MTU. "Layer 2 service MTU. It is also known
It is also known as the maximum transmission as the maximum transmission unit or
unit or maximum frame size."; maximum frame size.";
} }
leaf ce-vlan-preservation { leaf ce-vlan-preservation {
type boolean; type boolean;
description description
"Preserve the CE-VLAN ID from ingress to egress, i.e., "Preserves the CE VLAN ID from ingress to egress, i.e.,
CE-VLAN tag of the egress frame is identical to the CE VLAN tag of the egress frame is identical to
that of the ingress frame that yielded this egress that of the ingress frame that yielded this egress
service frame. If all-to-one bundling within a site service frame. If all-to-one bundling within a site
is enabled, then preservation applies to all ingress is enabled, then preservation applies to all ingress
service frames. If all-to-one bundling is disabled, service frames. If all-to-one bundling is disabled,
then preservation applies to tagged ingress service then preservation applies to tagged ingress service
frames having CE-VLAN ID 1 through 4094."; frames having CE VLAN ID 1 through 4094.";
} }
leaf ce-vlan-cos-preservation { leaf ce-vlan-cos-preservation {
type boolean; type boolean;
description description
"CE VLAN CoS preservation. Priority Code Point (PCP) bits "CE VLAN CoS preservation. Priority Code Point (PCP) bits
in the CE-VLAN tag of the egress frame are identical to in the CE VLAN tag of the egress frame are identical to
those of the ingress frame that yielded this egress those of the ingress frame that yielded this egress
service frame."; service frame.";
} }
leaf control-word-negotiation { leaf control-word-negotiation {
type boolean; type boolean;
description description
"Controls whether Control-word negotiation is enabled "Controls whether control-word negotiation is enabled
(if set to true) or not (if set to false)."; (if set to true) or not (if set to false).";
reference reference
"RFC 8077: Pseudowire Setup and Maintenance "RFC 8077: Pseudowire Setup and Maintenance
Using the Label Distribution Protocol (LDP), Using the Label Distribution Protocol (LDP),
Section 7"; Section 7";
} }
container mac-policies { container mac-policies {
description description
"Container of MAC policies."; "Container of MAC policies.";
container mac-addr-limit { container mac-addr-limit {
skipping to change at page 82, line 4 skipping to change at line 3611
description description
"Maximum number of MAC addresses learned from "Maximum number of MAC addresses learned from
the customer for a single service instance. the customer for a single service instance.
The default value is '2' when this grouping The default value is '2' when this grouping
is used at the service level."; is used at the service level.";
} }
leaf time-interval { leaf time-interval {
type uint32; type uint32;
units "milliseconds"; units "milliseconds";
description description
"The aging time of the mac address. "The aging time of the MAC address.
The default value is '300' when this grouping The default value is '300' when this grouping
is used at the service level."; is used at the service level.";
} }
leaf action { leaf action {
type identityref { type identityref {
base mac-action; base mac-action;
} }
description description
"Specifies the action when the upper limit is "Specifies the action when the upper limit is
exceeded: drop the packet, flood the packet, exceeded: drop the packet, flood the packet,
skipping to change at page 82, line 48 skipping to change at line 3655
within the 'window' time interval and the duplicate within the 'window' time interval and the duplicate
MAC address has been added to a list of duplicate MAC address has been added to a list of duplicate
MAC addresses. MAC addresses.
The default value is '5' when this grouping is The default value is '5' when this grouping is
called at the service level."; called at the service level.";
} }
leaf retry-timer { leaf retry-timer {
type uint32; type uint32;
units "seconds"; units "seconds";
description description
"The retry timer. When the retry timer expires, "The retry timer. When the retry timer expires,
the duplicate MAC address will be flushed from the duplicate MAC address will be flushed from
the MAC-VRF."; the MAC-VRF.";
} }
leaf protection-type { leaf protection-type {
type identityref { type identityref {
base loop-prevention-type; base loop-prevention-type;
} }
description description
"Protection type. "Protection type.
The default value is 'trap' when this grouping The default value is 'trap' when this grouping
skipping to change at page 83, line 46 skipping to change at line 3701
} }
} }
grouping bandwidth-parameters { grouping bandwidth-parameters {
description description
"A grouping for bandwidth parameters."; "A grouping for bandwidth parameters.";
leaf cir { leaf cir {
type uint64; type uint64;
units "bps"; units "bps";
description description
"Committed Information Rate. The maximum "Committed Information Rate (CIR). The maximum
number of bits that a port can receive or number of bits that a port can receive or
send during one-second over an send during one second over an
interface."; interface.";
} }
leaf cbs { leaf cbs {
type uint64; type uint64;
units "bytes"; units "bytes";
description description
"Committed Burst Size. CBS controls the "Committed Burst Size (CBS). CBS controls the
bursty nature of the traffic. Traffic bursty nature of the traffic. Traffic
that does not use the configured CIR that does not use the configured CIR
accumulates credits until the credits accumulates credits until the credits
reach the configured CBS."; reach the configured CBS.";
} }
leaf eir { leaf eir {
type uint64; type uint64;
units "bps"; units "bps";
description description
"Excess Information Rate, i.e., excess "Excess Information Rate (EIR), i.e., excess
frame delivery allowed not subject to frame delivery allowed not subject to
SLA. The traffic rate can be limited a Service Level Agreement (SLA). The
by EIR."; traffic rate can be limited by EIR.";
} }
leaf ebs { leaf ebs {
type uint64; type uint64;
units "bytes"; units "bytes";
description description
"Excess Burst Size. The bandwidth "Excess Burst Size (EBS). The bandwidth
available for burst traffic from the available for burst traffic from the
EBS is subject to the amount of EBS is subject to the amount of
bandwidth that is accumulated during bandwidth that is accumulated during
periods when traffic allocated by the periods when traffic allocated by the
EIR policy is not used."; EIR policy is not used.";
} }
leaf pir { leaf pir {
type uint64; type uint64;
units "bps"; units "bps";
description description
"Peak Information Rate, i.e., maximum "Peak Information Rate (PIR), i.e., maximum
frame delivery allowed. It is equal frame delivery allowed. It is equal
to or less than sum of CIR and EIR."; to or less than sum of CIR and EIR.";
} }
leaf pbs { leaf pbs {
type uint64; type uint64;
units "bytes"; units "bytes";
description description
"Peak Burst Size."; "Peak Burst Size (PBS).";
} }
} }
/* Main L2NM Container */ /* Main L2NM Container */
container l2vpn-ntw { container l2vpn-ntw {
description description
"Container for the L2NM."; "Container for the L2NM.";
container vpn-profiles { container vpn-profiles {
description description
skipping to change at page 85, line 41 skipping to change at line 3792
error-message "L3VPN is only applicable in L3NM."; error-message "L3VPN is only applicable in L3NM.";
} }
description description
"Service type."; "Service type.";
} }
leaf vpn-service-topology { leaf vpn-service-topology {
type identityref { type identityref {
base vpn-common:vpn-topology; base vpn-common:vpn-topology;
} }
description description
"Defining service topology, such as "Defines service topology such as
any-to-any, hub-spoke, etc."; any-to-any, hub-spoke, etc.";
} }
leaf bgp-ad-enabled { leaf bgp-ad-enabled {
type boolean; type boolean;
description description
"Indicates whether BGP auto-discovery is enabled "Indicates whether BGP auto-discovery is enabled
or disabled."; or disabled.";
} }
leaf signaling-type { leaf signaling-type {
type identityref { type identityref {
skipping to change at page 87, line 6 skipping to change at line 3853
} }
leaf description { leaf description {
type string; type string;
description description
"Textual description of a VPN node."; "Textual description of a VPN node.";
} }
leaf ne-id { leaf ne-id {
type string; type string;
description description
"An identifier of the network element where "An identifier of the network element where
the VPN node is deployed. This identifier the VPN node is deployed. This identifier
uniquely identifies the network element within uniquely identifies the network element within
an administrative domain."; an administrative domain.";
} }
leaf role { leaf role {
type identityref { type identityref {
base vpn-common:role; base vpn-common:role;
} }
default "vpn-common:any-to-any-role"; default "vpn-common:any-to-any-role";
description description
"Role of the VPN node in the VPN."; "Role of the VPN node in the VPN.";
} }
leaf router-id { leaf router-id {
type rt-types:router-id; type rt-types:router-id;
description description
"A 32-bit number in the dotted-quad format that is "A 32-bit number in the dotted-quad format that is
used to uniquely identify a node within an used to uniquely identify a node within an
autonomous system (AS)."; Autonomous System (AS).";
} }
container active-global-parameters-profiles { container active-global-parameters-profiles {
description description
"Container for a list of global parameters "Container for a list of global parameters
profiles."; profiles.";
list global-parameters-profile { list global-parameters-profile {
key "profile-id"; key "profile-id";
description description
"List of active global parameters profiles."; "List of active global parameters profiles.";
leaf profile-id { leaf profile-id {
skipping to change at page 87, line 47 skipping to change at line 3894
} }
description description
"Points to a global profile defined at the "Points to a global profile defined at the
service level."; service level.";
} }
uses parameters-profile; uses parameters-profile;
} }
} }
uses vpn-common:service-status; uses vpn-common:service-status;
container bgp-auto-discovery { container bgp-auto-discovery {
when "../../../bgp-ad-enabled = 'true'" { when "../../../bgp-ad-enabled = 'true'" {
description description
"Only applies when BGP auto-discovery is enabled."; "Only applies when BGP auto-discovery is enabled.";
} }
description description
"BGP is used for auto-discovery."; "BGP is used for auto-discovery.";
choice bgp-type { choice bgp-type {
description description
"Choice for the BGP type."; "Choice for the BGP type.";
case l2vpn-bgp { case l2vpn-bgp {
description description
"Container for BGP L2VPN."; "Container for BGP L2VPN.";
leaf vpn-id { leaf vpn-id {
type vpn-common:vpn-id; type vpn-common:vpn-id;
description description
"VPN Identifier. This identifier serves to "VPN Identifier. This identifier serves to
unify components of a given VPN for the unify components of a given VPN for the
sake of auto-discovery."; sake of auto-discovery.";
reference reference
"RFC 6624: Layer 2 Virtual Private Networks "RFC 6624: Layer 2 Virtual Private Networks
Using BGP for Auto-Discovery and Using BGP for Auto-Discovery and
Signaling"; Signaling";
} }
} }
case evpn-bgp { case evpn-bgp {
description description
skipping to change at page 90, line 31 skipping to change at line 4022
when "derived-from-or-self(../../../../" when "derived-from-or-self(../../../../"
+ "vpn-type, 'vpn-common:vpls')" { + "vpn-type, 'vpn-common:vpls')" {
description description
"Only applies for VPLS."; "Only applies for VPLS.";
} }
description description
"VPLS instance."; "VPLS instance.";
leaf vpls-edge-id { leaf vpls-edge-id {
type uint16; type uint16;
description description
"VPLS Edge Identifier (VE ID). This is "VPLS Edge Identifier (VE ID). This is
used when the same VE ID is configured used when the same VE ID is configured
for the PE."; for the PE.";
reference reference
"RFC 4761: Virtual Private LAN Service "RFC 4761: Virtual Private LAN Service
(VPLS) Using BGP for Auto- (VPLS) Using BGP for Auto-
Discovery and Signaling, Discovery and Signaling,
Section 3.5"; Section 3.5";
} }
leaf vpls-edge-id-range { leaf vpls-edge-id-range {
type uint16; type uint16;
skipping to change at page 91, line 42 skipping to change at line 4080
base mac-learning-mode; base mac-learning-mode;
} }
description description
"Indicates through which plane MAC "Indicates through which plane MAC
addresses are advertised."; addresses are advertised.";
} }
leaf ingress-replication { leaf ingress-replication {
type boolean; type boolean;
description description
"Controls whether ingress replication is "Controls whether ingress replication is
enabled ('true') or disabled ('false')."; enabled ('true') or disabled
('false').";
reference reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, "RFC 7432: BGP MPLS-Based Ethernet VPN,
Section 8.3.1.1"; Section 8.3.1.1";
} }
leaf p2mp-replication { leaf p2mp-replication {
type boolean; type boolean;
description description
"Controles whether P2MP replication is "Controls whether Point-to-Multipoint
enabled ('true') or disabled ('false')"; (P2MP) replication is enabled ('true')
or disabled ('false')";
reference reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, "RFC 7432: BGP MPLS-Based Ethernet VPN,
Section 8.3.1.2"; Section 8.3.1.2";
} }
container arp-proxy { container arp-proxy {
if-feature "vpn-common:ipv4"; if-feature "vpn-common:ipv4";
description description
"Top container for the ARP proxy."; "Top container for the ARP proxy.";
leaf enable { leaf enable {
type boolean; type boolean;
default "false"; default "false";
description description
"Enables (when set to 'true') or "Enables (when set to 'true') or
disables (when set to 'false') disables (when set to 'false')
ARP proxy."; the ARP proxy.";
reference reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, "RFC 7432: BGP MPLS-Based Ethernet VPN,
Section 10"; Section 10";
} }
leaf arp-suppression { leaf arp-suppression {
type boolean; type boolean;
default "false"; default "false";
description description
"Enables (when set to 'true') or "Enables (when set to 'true') or
disables (when set to 'false') ARP disables (when set to 'false') ARP
suppression."; suppression.";
reference reference
"RFC 7432: BGP MPLS-Based Ethernet "RFC 7432: BGP MPLS-Based Ethernet
VPN"; VPN";
} }
leaf ip-mobility-threshold { leaf ip-mobility-threshold {
type uint16; type uint16;
description description
"It is possible for a given host (as "It is possible for a given host (as
defined by its IP address) to move defined by its IP address) to move
from one ES to another. from one ES to another. The
IP mobility threshold specifies the IP mobility threshold specifies the
number of IP mobility events number of IP mobility events
that are detected for a given IP that are detected for a given IP
address within the address within the
detection-threshold before it detection-threshold before it
is identified as a duplicate IP is identified as a duplicate IP
address. address. Once the detection threshold
Once the detection threshold is is reached, updates for the IP address
reached, updates for the IP address
are suppressed."; are suppressed.";
} }
leaf duplicate-ip-detection-interval { leaf duplicate-ip-detection-interval {
type uint16; type uint16;
units "seconds"; units "seconds";
description description
"The time interval used in detecting a "The time interval used in detecting a
duplicate IP address. Duplicate IP duplicate IP address. Duplicate IP
address detection number of host moves address detection number of host moves
are allowed within this interval are allowed within this interval
period."; period.";
} }
} }
container nd-proxy { container nd-proxy {
if-feature "vpn-common:ipv6"; if-feature "vpn-common:ipv6";
description description
"Top container for the ND proxy."; "Top container for the ND proxy.";
leaf enable { leaf enable {
type boolean; type boolean;
default "false"; default "false";
description description
"Enables (when set to 'true') or "Enables (when set to 'true') or
disables (when set to 'false') ND disables (when set to 'false') the
proxy."; ND proxy.";
reference reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, "RFC 7432: BGP MPLS-Based Ethernet VPN,
Section 10"; Section 10";
} }
leaf nd-suppression { leaf nd-suppression {
type boolean; type boolean;
default "false"; default "false";
description description
"Enables (when set to 'true') or "Enables (when set to 'true') or
disables (when set to 'false') disables (when set to 'false')
Neighbor Discovery (ND) message Neighbor Discovery (ND) message
suppression. suppression.
ND suppression is a technique that ND suppression is a technique that
is used to reduce the amount of ND is used to reduce the amount of ND
packets flooding within individual packets flooding within individual
segments, that is between hosts segments between hosts
connected to the same logical connected to the same logical
switch."; switch.";
} }
leaf ip-mobility-threshold { leaf ip-mobility-threshold {
type uint16; type uint16;
description description
"It is possible for a given host (as "It is possible for a given host (as
defined by its IP address) to move defined by its IP address) to move
from one ES to another. from one ES to another. The
IP mobility threshold specifies the IP mobility threshold specifies the
number of IP mobility events number of IP mobility events
that are detected for a given IP that are detected for a given IP
address within the address within the
detection-threshold before it detection-threshold before it
is identified as a duplicate IP is identified as a duplicate IP
address. address.
Once the detection threshold is Once the detection threshold is
reached, updates for the IP address reached, updates for the IP address
are suppressed."; are suppressed.";
} }
leaf duplicate-ip-detection-interval { leaf duplicate-ip-detection-interval {
type uint16; type uint16;
units "seconds"; units "seconds";
description description
"The time interval used in detecting a "The time interval used in detecting a
duplicate IP address. Duplicate IP duplicate IP address. Duplicate IP
address detection number of host moves address detection number of host moves
are allowed within this interval are allowed within this interval
period."; period.";
} }
} }
leaf underlay-multicast { leaf underlay-multicast {
type boolean; type boolean;
default "false"; default "false";
description description
"Enables (when set to 'true') or disables "Enables (when set to 'true') or disables
(when set to 'false') underlay (when set to 'false') underlay
multicast."; multicast.";
} }
leaf flood-unknown-unicast-supression { leaf flood-unknown-unicast-suppression {
type boolean; type boolean;
default "false"; default "false";
description description
"Enables (when set to 'true') or disables "Enables (when set to 'true') or disables
(when set to 'false') unknown flood (when set to 'false') unknown flood
unicast suppression."; unicast suppression.";
} }
leaf vpws-vlan-aware { leaf vpws-vlan-aware {
type boolean; type boolean;
default "false"; default "false";
description description
"Enables (when set to 'true') or disables "Enables (when set to 'true') or disables
(when set to 'false') VPWS VLAN-aware."; (when set to 'false') VPWS VLAN-aware
service for the EVPN instance.";
} }
container bum-management { container bum-management {
description description
"Broadcast-unknown-unicast-multicast "Broadcast-unknown-unicast-multicast
management."; management.";
leaf discard-broadcast { leaf discard-broadcast {
type boolean; type boolean;
default "false"; default "false";
description description
"Discards broadcast, when enabled."; "Discards broadcast, when enabled.";
skipping to change at page 95, line 32 skipping to change at line 4265
} }
container pbb { container pbb {
when "derived-from-or-self(" when "derived-from-or-self("
+ "../../evpn-type, 'pbb-evpn')" { + "../../evpn-type, 'pbb-evpn')" {
description description
"Only applies for PBB EVPN."; "Only applies for PBB EVPN.";
} }
description description
"PBB parameters container."; "PBB parameters container.";
reference reference
"IEEE 802.1ah: Provider Backbone Bridge"; "IEEE 802.1ah: Provider Backbone
Bridges";
leaf backbone-src-mac { leaf backbone-src-mac {
type yang:mac-address; type yang:mac-address;
description description
"Includes provider backbone MAC (B-MAC) "Includes Provider Backbone MAC (B-MAC)
address."; address.";
reference reference
"RFC 7623: Provider Backbone Bridging "RFC 7623: Provider Backbone Bridging
Combined with Ethernet VPN Combined with Ethernet VPN
(PBB-EVPN), Section 8.1"; (PBB-EVPN), Section 8.1";
} }
} }
} }
} }
} }
skipping to change at page 96, line 4 skipping to change at line 4286
} }
} }
} }
} }
} }
} }
container ldp-or-l2tp { container ldp-or-l2tp {
description description
"Container for LDP or L2TP-signaled PWs "Container for LDP or L2TP-signaled PWs
choice."; choice.";
leaf agi { leaf agi {
type rt-types:route-distinguisher; type rt-types:route-distinguisher;
description description
"Attachment Group Identifier. Also, called "Attachment Group Identifier. Also, called
VPLS-Id."; VPLS-Id.";
reference reference
"RFC 4667: Layer 2 Virtual Private Network "RFC 4667: Layer 2 Virtual Private Network
(L2VPN) Extensions for Layer 2 (L2VPN) Extensions for Layer 2
Tunneling Protocol (L2TP), Tunneling Protocol (L2TP),
Section 4.3 Section 4.3
RFC 4762: Virtual Private LAN Service (VPLS) RFC 4762: Virtual Private LAN Service (VPLS)
Using Label Distribution Protocol Using Label Distribution Protocol
(LDP) Signaling, Section 6.1.1"; (LDP) Signaling, Section 6.1.1";
} }
skipping to change at page 96, line 34 skipping to change at line 4315
reference reference
"RFC 4667: Layer 2 Virtual Private Network "RFC 4667: Layer 2 Virtual Private Network
(L2VPN) Extensions for Layer 2 (L2VPN) Extensions for Layer 2
Tunneling Protocol (L2TP), Tunneling Protocol (L2TP),
Section 3"; Section 3";
} }
list remote-targets { list remote-targets {
key "taii"; key "taii";
description description
"List of allowed target Attachment Individual "List of allowed target Attachment Individual
Identifier (AII) and peers."; Identifiers (AIIs) and peers.";
reference reference
"RFC 4667: Layer 2 Virtual Private Network "RFC 4667: Layer 2 Virtual Private Network
(L2VPN) Extensions for Layer 2 (L2VPN) Extensions for Layer 2
Tunneling Protocol (L2TP), Tunneling Protocol (L2TP),
Section 5"; Section 5";
leaf taii { leaf taii {
type uint32; type uint32;
description description
"Target Attachment Individual Identifier."; "Target Attachment Individual Identifier.";
reference reference
skipping to change at page 97, line 36 skipping to change at line 4366
reference reference
"RFC 4762: Virtual Private LAN Service "RFC 4762: Virtual Private LAN Service
(VPLS) Using Label Distribution (VPLS) Using Label Distribution
Protocol (LDP) Signaling, Protocol (LDP) Signaling,
Section 6.1.1"; Section 6.1.1";
} }
leaf pw-description { leaf pw-description {
type string; type string;
description description
"Includes a human-readable description "Includes a human-readable description
of the interface. This may be used when of the interface. This may be used when
communicating with a remote peer."; communicating with a remote peer.";
reference reference
"RFC 4762: Virtual Private LAN Service "RFC 4762: Virtual Private LAN Service
(VPLS) Using Label Distribution (VPLS) Using Label Distribution
Protocol (LDP) Signaling, Protocol (LDP) Signaling,
Section 6.1.1"; Section 6.1.1";
} }
leaf mac-addr-withdraw { leaf mac-addr-withdraw {
type boolean; type boolean;
description description
skipping to change at page 98, line 12 skipping to change at line 4390
disabled."; disabled.";
reference reference
"RFC 4762: Virtual Private LAN Service "RFC 4762: Virtual Private LAN Service
(VPLS) Using Label Distribution (VPLS) Using Label Distribution
Protocol (LDP) Signaling, Protocol (LDP) Signaling,
Section 6.2"; Section 6.2";
} }
list pw-peer-list { list pw-peer-list {
key "peer-addr vc-id"; key "peer-addr vc-id";
description description
"List of AC and PW bindings."; "List of attachment circuit (AC) and PW
bindings.";
leaf peer-addr { leaf peer-addr {
type inet:ip-address; type inet:ip-address;
description description
"Indicates the peer's IP address."; "Indicates the peer's IP address.";
} }
leaf vc-id { leaf vc-id {
type string; type string;
description description
"VC label used to identify a PW."; "VC label used to identify a PW.";
} }
skipping to change at page 98, line 36 skipping to change at line 4415
"Defines the priority for the PW. "Defines the priority for the PW.
The higher the pw-priority value, the The higher the pw-priority value, the
higher the preference of the PW will higher the preference of the PW will
be."; be.";
} }
} }
container qinq { container qinq {
when "derived-from-or-self(" when "derived-from-or-self("
+ "../t-ldp-pw-type, 'hvpls')" { + "../t-ldp-pw-type, 'hvpls')" {
description description
"Only applies when t-ldp pw type "Only applies when T-LDP PW type
is h-vpls."; is H-VPLS.";
} }
description description
"Container for QinQ."; "Container for QinQ.";
leaf s-tag { leaf s-tag {
type dot1q-types:vlanid; type dot1q-types:vlanid;
mandatory true; mandatory true;
description description
"S-TAG."; "S-TAG.";
} }
leaf c-tag { leaf c-tag {
skipping to change at page 99, line 50 skipping to change at line 4476
container vpn-network-accesses { container vpn-network-accesses {
description description
"Main container for VPN network accesses."; "Main container for VPN network accesses.";
list vpn-network-access { list vpn-network-access {
key "id"; key "id";
description description
"List of VPN network accesses."; "List of VPN network accesses.";
leaf id { leaf id {
type vpn-common:vpn-id; type vpn-common:vpn-id;
description description
"Identifier of the network access"; "Identifier of the network access.";
} }
leaf description { leaf description {
type string; type string;
description description
"A textual description of the VPN network "A textual description of the VPN network
access."; access.";
} }
leaf interface-id { leaf interface-id {
type string; type string;
description description
"Refers to a physical or logical interface."; "Refers to a physical or logical interface.";
} }
leaf active-vpn-node-profile { leaf active-vpn-node-profile {
type leafref { type leafref {
path "../../.." path "../../.."
+ "/active-global-parameters-profiles" + "/active-global-parameters-profiles"
+ "/global-parameters-profile/profile-id"; + "/global-parameters-profile/profile-id";
} }
description description
"An identifier of an active VPN instance "An identifier of an active VPN instance
profile."; profile.";
} }
uses vpn-common:service-status; uses vpn-common:service-status;
container connection { container connection {
description description
skipping to change at page 101, line 12 skipping to change at line 4535
} }
container encapsulation { container encapsulation {
description description
"Container for Layer 2 encapsulation."; "Container for Layer 2 encapsulation.";
leaf encap-type { leaf encap-type {
type identityref { type identityref {
base vpn-common:encapsulation-type; base vpn-common:encapsulation-type;
} }
default "vpn-common:priority-tagged"; default "vpn-common:priority-tagged";
description description
"Tagged interface type. By default, the "Tagged interface type. By default, the
type of the tagged interface is type of the tagged interface is
'priority-tagged'."; 'priority-tagged'.";
} }
container dot1q { container dot1q {
when "derived-from-or-self(../encap-type, " when "derived-from-or-self(../encap-type, "
+ "'vpn-common:dot1q')" { + "'vpn-common:dot1q')" {
description description
"Only applies when the type of the "Only applies when the type of the
tagged interface is 'dot1q'."; tagged interface is 'dot1q'.";
} }
description description
"Tagged interface."; "Tagged interface.";
leaf tag-type { leaf tag-type {
type identityref { type identityref {
base vpn-common:tag-type; base vpn-common:tag-type;
} }
default "vpn-common:c-vlan"; default "vpn-common:c-vlan";
description description
"Tag type. By default, the tag type is "Tag type. By default, the tag type is
'c-vlan'."; 'c-vlan'.";
} }
leaf cvlan-id { leaf cvlan-id {
type dot1q-types:vlanid; type dot1q-types:vlanid;
description description
"VLAN identifier."; "VLAN identifier.";
} }
container tag-operations { container tag-operations {
description description
"Sets the tag manipulation policy for this "Sets the tag manipulation policy for this
VPN network access. It defines a set of VPN network access. It defines a set of
tag manipulations that allow for the tag manipulations that allow for the
insertion, removal, or rewriting insertion, removal, or rewriting
of 802.1Q VLAN tags. These operations are of 802.1Q VLAN tags. These operations are
indicated for the CE-PE direction. indicated for the CE-PE direction.
By default, tag operations are symmetric. By default, tag operations are symmetric.
As such, the reverse tag operation is As such, the reverse tag operation is
assumed on the PE-CE direction."; assumed on the PE-CE direction.";
choice op-choice { choice op-choice {
description description
"Selects the tag rewriting policy for a "Selects the tag rewriting policy for a
VPN network access."; VPN network access.";
leaf pop { leaf pop {
type empty; type empty;
description description
"Pop the outer tag."; "Pop the outer tag.";
} }
leaf push { leaf push {
type empty; type empty;
description description
"Push one or two tags defined by the "Pushes one or two tags defined by the
tag-1 and tag-2 leaves. It is tag-1 and tag-2 leaves. It is
assumed that, absent any policy, the assumed that, absent any policy, the
default value of 0 will be used for default value of 0 will be used for
PCP setting."; the PCP setting.";
} }
leaf translate { leaf translate {
type empty; type empty;
description description
"Translate the outer tag to one or two "Translates the outer tag to one or two
tags. PCP bits are preserved."; tags. PCP bits are preserved.";
} }
} }
leaf tag-1 { leaf tag-1 {
when 'not(../pop)'; when 'not(../pop)';
type dot1q-types:vlanid; type dot1q-types:vlanid;
description description
"A first tag to be used for push or "A first tag to be used for push or
translate operations. This tag will be translate operations. This tag will be
used as the outermost tag as a result used as the outermost tag as a result
of the tag operation."; of the tag operation.";
} }
leaf tag-1-type { leaf tag-1-type {
type dot1q-types:dot1q-tag-type; type dot1q-types:dot1q-tag-type;
default "dot1q-types:s-vlan"; default "dot1q-types:s-vlan";
description description
"Specifies a specific 802.1Q tag type "Specifies a specific 802.1Q tag type
of tag-1."; of tag-1.";
} }
skipping to change at page 103, line 26 skipping to change at line 4645
tagged interface is 'priority-tagged'."; tagged interface is 'priority-tagged'.";
} }
description description
"Priority tagged container."; "Priority tagged container.";
leaf tag-type { leaf tag-type {
type identityref { type identityref {
base vpn-common:tag-type; base vpn-common:tag-type;
} }
default "vpn-common:c-vlan"; default "vpn-common:c-vlan";
description description
"Tag type. By default, the tag type is "Tag type. By default, the tag type is
'c-vlan'."; 'c-vlan'.";
} }
} }
container qinq { container qinq {
when "derived-from-or-self(../encap-type, " when "derived-from-or-self(../encap-type, "
+ "'vpn-common:qinq')" { + "'vpn-common:qinq')" {
description description
"Only applies when the type of the tagged "Only applies when the type of the tagged
interface is QinQ."; interface is 'QinQ'.";
} }
description description
"Includes QinQ parameters."; "Includes QinQ parameters.";
leaf tag-type { leaf tag-type {
type identityref { type identityref {
base vpn-common:tag-type; base vpn-common:tag-type;
} }
default "vpn-common:s-c-vlan"; default "vpn-common:s-c-vlan";
description description
"Tag type. By default, the tag type is "Tag type. By default, the tag type is
's-c-vlan'."; 's-c-vlan'.";
} }
leaf svlan-id { leaf svlan-id {
type dot1q-types:vlanid; type dot1q-types:vlanid;
mandatory true; mandatory true;
description description
"S-VLAN identifier."; "S-VLAN identifier.";
} }
leaf cvlan-id { leaf cvlan-id {
type dot1q-types:vlanid; type dot1q-types:vlanid;
mandatory true; mandatory true;
description description
"C-VLAN identifier."; "C-VLAN identifier.";
} }
container tag-operations { container tag-operations {
description description
"Sets the tag manipulation policy for this "Sets the tag manipulation policy for this
VPN network access. It defines a set of VPN network access. It defines a set of
tag manipulations that allow for the tag manipulations that allow for the
insertion, removal, or rewriting insertion, removal, or rewriting
of 802.1Q VLAN tags. These operations are of 802.1Q VLAN tags. These operations are
indicated for the CE-PE direction. indicated for the CE-PE direction.
By default, tag operations are symmetric. By default, tag operations are symmetric.
As such, the reverse tag operation is As such, the reverse tag operation is
assumed on the PE-CE direction."; assumed on the PE-CE direction.";
choice op-choice { choice op-choice {
description description
"Selects the tag rewriting policy for a "Selects the tag rewriting policy for a
VPN network access."; VPN network access.";
leaf pop { leaf pop {
type uint8 { type uint8 {
range "1|2"; range "1|2";
} }
description description
"Pop one or two tags as a function "Pops one or two tags as a function
of the indicated pop value."; of the indicated pop value.";
} }
leaf push { leaf push {
type empty; type empty;
description description
"Push one or two tags defined by the "Pushes one or two tags defined by the
tag-1 and tag-2 leaves. It is tag-1 and tag-2 leaves. It is
assumed that, absent any policy, the assumed that, absent any policy, the
default value of 0 will be used for default value of 0 will be used for
PCP setting."; PCP setting.";
} }
leaf translate { leaf translate {
type uint8 { type uint8 {
range "1|2"; range "1|2";
} }
description description
"Translate one or two outer tags. PCP "Translates one or two outer tags. PCP
bits are preserved. bits are preserved.
The following operations are The following operations are
supported: supported:
- translate 1 with tag-1 leaf is - translate 1 with tag-1 leaf is
provided: only the outermost tag is provided: only the outermost tag is
translated to the value in tag-1. translated to the value in tag-1.
- translate 2 with both tag-1 and - translate 2 with both tag-1 and
skipping to change at page 105, line 29 skipping to change at line 4743
provided: the outer tag is popped provided: the outer tag is popped
while the inner tag is translated while the inner tag is translated
to the value in tag-1."; to the value in tag-1.";
} }
} }
leaf tag-1 { leaf tag-1 {
when 'not(../pop)'; when 'not(../pop)';
type dot1q-types:vlanid; type dot1q-types:vlanid;
description description
"A first tag to be used for push or "A first tag to be used for push or
translate operations. This tag will be translate operations. This tag will be
used as the outermost tag as a result used as the outermost tag as a result
of the tag operation."; of the tag operation.";
} }
leaf tag-1-type { leaf tag-1-type {
type dot1q-types:dot1q-tag-type; type dot1q-types:dot1q-tag-type;
default "dot1q-types:s-vlan"; default "dot1q-types:s-vlan";
description description
"Specifies a specific 802.1Q tag type "Specifies a specific 802.1Q tag type
of tag-1."; of tag-1.";
} }
skipping to change at page 106, line 40 skipping to change at line 4802
base lacp-mode; base lacp-mode;
} }
description description
"Indicates the LACP mode."; "Indicates the LACP mode.";
} }
leaf speed { leaf speed {
type uint32; type uint32;
units "mbps"; units "mbps";
default "10"; default "10";
description description
"LACP speed. This low default value "LACP speed. This low default value
is inherited from the L2SM."; is inherited from the L2SM.";
} }
leaf mini-link-num { leaf mini-link-num {
type uint32; type uint32;
description description
"Defines the minimum number of links that "Defines the minimum number of links that
must be active before the aggregating must be active before the aggregating
link is put into service."; link is put into service.";
} }
leaf system-id { leaf system-id {
skipping to change at page 108, line 4 skipping to change at line 4863
base vpn-common:neg-mode; base vpn-common:neg-mode;
} }
description description
"Negotiation mode."; "Negotiation mode.";
} }
leaf link-mtu { leaf link-mtu {
type uint32; type uint32;
units "bytes"; units "bytes";
description description
"Link MTU size."; "Link MTU size.";
} }
container oam-802.3ah-link { container oam-802.3ah-link {
if-feature "oam-3ah"; if-feature "oam-3ah";
description description
"Container for oam 802.3ah link."; "Container for the OAM 802.3ah
link.";
leaf enable { leaf enable {
type boolean; type boolean;
default "false"; default "false";
description description
"Indicates support of OAM 802.3ah "Indicates support of the OAM
link."; 802.3ah link.";
} }
} }
} }
} }
leaf flow-control { leaf flow-control {
type boolean; type boolean;
default "false"; default "false";
description description
"Indicates whether flow control is "Indicates whether flow control is
supported."; supported.";
} }
leaf lldp { leaf lldp {
type boolean; type boolean;
default "false"; default "false";
description description
"Indicates whether Link Layer Discovery "Indicates whether the Link Layer
Protocol (LLDP) is supported."; Discovery Protocol (LLDP) is
supported.";
} }
} }
container split-horizon { container split-horizon {
description description
"Configuration with split horizon enabled."; "Configuration with Split Horizon enabled.";
leaf group-name { leaf group-name {
type string; type string;
description description
"Group name of the Split Horizon."; "Group name of the Split Horizon.";
} }
} }
} }
} }
choice signaling-option { choice signaling-option {
description description
skipping to change at page 110, line 9 skipping to change at line 4966
"Used for EVPN."; "Used for EVPN.";
leaf df-preference { leaf df-preference {
type uint16; type uint16;
default "32767"; default "32767";
description description
"Defines a 2-octet value that indicates "Defines a 2-octet value that indicates
the PE preference to become the DF in the PE preference to become the DF in
the ES. the ES.
The preference value is only applicable The preference value is only applicable
to the preference based method."; to the preference-based method.";
reference reference
"RFC 8584: Framework for Ethernet VPN "RFC 8584: Framework for Ethernet VPN
Designated Forwarder Election Designated Forwarder Election
Extensibility"; Extensibility";
} }
container vpws-service-instance { container vpws-service-instance {
when "derived-from-or-self(../../../../../" when "derived-from-or-self(../../../../../"
+ "vpn-type, 'vpn-common:vpws-evpn')" { + "vpn-type, 'vpn-common:vpws-evpn')" {
description description
"Only applies for EVPN-VPWS."; "Only applies for EVPN-VPWS.";
skipping to change at page 110, line 51 skipping to change at line 5008
} }
case auto-assigned { case auto-assigned {
description description
"The local VSI is auto-assigned."; "The local VSI is auto-assigned.";
container local-vsi-auto { container local-vsi-auto {
description description
"The local VSI is auto-assigned."; "The local VSI is auto-assigned.";
choice auto-mode { choice auto-mode {
description description
"Indicates the auto-assignment "Indicates the auto-assignment
mode of local VSI. VSI can be mode of local VSI. VSI can be
automatically assigned either automatically assigned either
with or without indicating a with or without indicating a
pool from which the VSI pool from which the VSI
should be taken. should be taken.
For both cases, the server For both cases, the server
will auto-assign a local VSI will auto-assign a local VSI
value and use that value."; value and use that value.";
case from-pool { case from-pool {
leaf vsi-pool-name { leaf vsi-pool-name {
skipping to change at page 112, line 17 skipping to change at line 5070
} }
case auto-assigned { case auto-assigned {
description description
"The remote VSI is auto-assigned."; "The remote VSI is auto-assigned.";
container remote-vsi-auto { container remote-vsi-auto {
description description
"The remote VSI is auto-assigned."; "The remote VSI is auto-assigned.";
choice auto-mode { choice auto-mode {
description description
"Indicates the auto-assignment "Indicates the auto-assignment
mode of remote VSI. VSI can be mode of remote VSI. VSI can be
automatically assigned either automatically assigned either
with or without indicating a with or without indicating a
pool from which the VSI pool from which the VSI
should be taken. should be taken.
For both cases, the server For both cases, the server
will auto-assign a remote VSI will auto-assign a remote VSI
value and use that value."; value and use that value.";
case from-pool { case from-pool {
leaf vsi-pool-name { leaf vsi-pool-name {
skipping to change at page 113, line 28 skipping to change at line 5128
type string; type string;
description description
"Indicates the group-id to which the network "Indicates the group-id to which the network
access belongs to."; access belongs to.";
} }
leaf precedence { leaf precedence {
type identityref { type identityref {
base precedence-type; base precedence-type;
} }
description description
"Defining service redundancy in transport "Defines service redundancy in transport
network."; network.";
} }
leaf ethernet-segment-identifier { leaf ethernet-segment-identifier {
type l2vpn-es:es-ref; type l2vpn-es:es-ref;
description description
"Reference to the ESI associated with the VPN "Reference to the ESI associated with the VPN
network access."; network access.";
} }
} }
container ethernet-service-oam { container ethernet-service-oam {
skipping to change at page 114, line 27 skipping to change at line 5176
} }
uses y-1731; uses y-1731;
} }
container service { container service {
description description
"Container for service"; "Container for service";
leaf mtu { leaf mtu {
type uint32; type uint32;
units "bytes"; units "bytes";
description description
"Layer 2 MTU, it is also known as the maximum "Layer 2 MTU; it is also known as the maximum
transmission unit or maximum frame size."; transmission unit or maximum frame size.";
} }
container svc-pe-to-ce-bandwidth { container svc-pe-to-ce-bandwidth {
if-feature "vpn-common:inbound-bw"; if-feature "vpn-common:inbound-bw";
description description
"From the customer site's perspective, the "From the customer site's perspective, the
service inbound bandwidth of the connection service inbound bandwidth of the connection
or download bandwidth from the service or download bandwidth from the service
provider the site. Note that the L2SM uses provider to the site. Note that the L2SM uses
'input-bandwidth' to refer to the same 'input-bandwidth' to refer to the same
concept."; concept.";
list pe-to-ce-bandwidth { list pe-to-ce-bandwidth {
key "bw-type"; key "bw-type";
description description
"List for PE-to-CE bandwidth data nodes."; "List for PE-to-CE bandwidth data nodes.";
leaf bw-type { leaf bw-type {
type identityref { type identityref {
base vpn-common:bw-type; base vpn-common:bw-type;
} }
skipping to change at page 115, line 11 skipping to change at line 5208
} }
choice type { choice type {
description description
"Choice based upon bandwidth type."; "Choice based upon bandwidth type.";
case per-cos { case per-cos {
description description
"Bandwidth per CoS."; "Bandwidth per CoS.";
list cos { list cos {
key "cos-id"; key "cos-id";
description description
"List of class of services."; "List of Class of Services.";
leaf cos-id { leaf cos-id {
type uint8; type uint8;
description description
"Identifier of the CoS, indicated by "Identifier of the CoS, indicated by
DSCP or a CE-CLAN CoS (802.1p) value a Differentiated Services Code Point
in the service frame."; (DSCP) or a CE-CLAN CoS (802.1p)
value in the service frame.";
reference reference
"IEEE Std 802.1Q: Bridges and Bridged "IEEE Std 802.1Q: Bridges and Bridged
Networks"; Networks";
} }
uses bandwidth-parameters; uses bandwidth-parameters;
} }
} }
case other { case other {
description description
"Other bandwidth types."; "Other bandwidth types.";
skipping to change at page 115, line 39 skipping to change at line 5237
} }
} }
} }
} }
container svc-ce-to-pe-bandwidth { container svc-ce-to-pe-bandwidth {
if-feature "vpn-common:outbound-bw"; if-feature "vpn-common:outbound-bw";
description description
"From the customer site's perspective, "From the customer site's perspective,
the service outbound bandwidth of the the service outbound bandwidth of the
connection or upload bandwidth from connection or upload bandwidth from
the CE to the PE. Note that the L2SM uses the CE to the PE. Note that the L2SM uses
'output-bandwidth' to refer to the same 'output-bandwidth' to refer to the same
concept."; concept.";
list ce-to-pe-bandwidth { list ce-to-pe-bandwidth {
key "bw-type"; key "bw-type";
description description
"List for CE-to-PE bandwidth."; "List for CE-to-PE bandwidth.";
leaf bw-type { leaf bw-type {
type identityref { type identityref {
base vpn-common:bw-type; base vpn-common:bw-type;
} }
skipping to change at page 116, line 4 skipping to change at line 5250
list ce-to-pe-bandwidth { list ce-to-pe-bandwidth {
key "bw-type"; key "bw-type";
description description
"List for CE-to-PE bandwidth."; "List for CE-to-PE bandwidth.";
leaf bw-type { leaf bw-type {
type identityref { type identityref {
base vpn-common:bw-type; base vpn-common:bw-type;
} }
description description
"Indicates the bandwidth type."; "Indicates the bandwidth type.";
} }
choice type { choice type {
description description
"Choice based upon bandwidth type."; "Choice based upon bandwidth type.";
case per-cos { case per-cos {
description description
"Bandwidth per CoS."; "Bandwidth per CoS.";
list cos { list cos {
key "cos-id"; key "cos-id";
description description
"List of class of services."; "List of Class of Services.";
leaf cos-id { leaf cos-id {
type uint8; type uint8;
description description
"Identifier of the CoS, indicated by "Identifier of the CoS, indicated by
DSCP or a CE-CLAN CoS (802.1p) value DSCP or a CE-CLAN CoS (802.1p) value
in the service frame."; in the service frame.";
reference reference
"IEEE Std 802.1Q: Bridges and Bridged "IEEE Std 802.1Q: Bridges and Bridged
Networks"; Networks";
} }
skipping to change at page 118, line 39 skipping to change at line 5381
} }
} }
} }
container qos-profile { container qos-profile {
description description
"QoS profile configuration."; "QoS profile configuration.";
list qos-profile { list qos-profile {
key "profile"; key "profile";
description description
"QoS profile. "QoS profile.
Can be standard profile or customized Can be a standard or customized
profile."; profile.";
leaf profile { leaf profile {
type leafref { type leafref {
path "/l2vpn-ntw/vpn-profiles" path "/l2vpn-ntw/vpn-profiles"
+ "/valid-provider-identifiers" + "/valid-provider-identifiers"
+ "/qos-profile-identifier/id"; + "/qos-profile-identifier/id";
} }
description description
"QoS profile to be used."; "QoS profile to be used.";
} }
skipping to change at page 119, line 20 skipping to change at line 5410
} }
} }
} }
} }
container mac-policies { container mac-policies {
description description
"Container for MAC-related policies."; "Container for MAC-related policies.";
list access-control-list { list access-control-list {
key "name"; key "name";
description description
"Container for access control List."; "Container for the Access Control List
(ACL).";
leaf name { leaf name {
type string; type string;
description description
"Specifies the name of the ACL."; "Specifies the name of the ACL.";
} }
leaf-list src-mac-address { leaf-list src-mac-address {
type yang:mac-address; type yang:mac-address;
description description
"Specifies the source MAC address."; "Specifies the source MAC address.";
} }
skipping to change at page 120, line 48 skipping to change at line 5487
duplication, where a 'duplicate MAC duplication, where a 'duplicate MAC
address' situation has occurred and address' situation has occurred and
the duplicate MAC address has been the duplicate MAC address has been
added to a list of duplicate MAC added to a list of duplicate MAC
addresses."; addresses.";
} }
leaf retry-timer { leaf retry-timer {
type uint32; type uint32;
units "seconds"; units "seconds";
description description
"The retry timer. When the retry timer "The retry timer. When the retry timer
expires, the duplicate MAC address will expires, the duplicate MAC address will
be flushed from the MAC-VRF."; be flushed from the MAC-VRF.";
} }
leaf protection-type { leaf protection-type {
type identityref { type identityref {
base loop-prevention-type; base loop-prevention-type;
} }
default "trap"; default "trap";
description description
"Protection type"; "Protection type";
} }
} }
container mac-addr-limit { container mac-addr-limit {
description description
"Container of MAC-Addr limit configurations"; "Container of MAC-Addr limit
configurations.";
leaf limit-number { leaf limit-number {
type uint16; type uint16;
default "2"; default "2";
description description
"Maximum number of MAC addresses learned "Maximum number of MAC addresses learned
from the subscriber for a single service from the subscriber for a single service
instance."; instance.";
} }
leaf time-interval { leaf time-interval {
type uint32; type uint32;
units "milliseconds"; units "milliseconds";
default "300"; default "300";
description description
"The aging time of the mac address."; "The aging time of the MAC address.";
} }
leaf action { leaf action {
type identityref { type identityref {
base mac-action; base mac-action;
} }
default "warning"; default "warning";
description description
"Specifies the action when the upper limit "Specifies the action when the upper limit
is exceeded: drop the packet, flood the is exceeded: drop the packet, flood the
packet, or log a warning message (without packet, or log a warning message (without
dropping the packet)."; dropping the packet).";
} }
} }
} }
container broadcast-unknown-unicast-multicast { container broadcast-unknown-unicast-multicast {
description description
"Container of broadcast, unknown unicast, and "Container of broadcast, unknown unicast, or
multicast configurations"; multicast configurations.";
leaf multicast-site-type { leaf multicast-site-type {
type enumeration { type enumeration {
enum receiver-only { enum receiver-only {
description description
"The site only has receivers."; "The site only has receivers.";
} }
enum source-only { enum source-only {
description description
"The site only has sources."; "The site only has sources.";
} }
skipping to change at page 122, line 23 skipping to change at line 5559
receivers."; receivers.";
} }
} }
default "source-receiver"; default "source-receiver";
description description
"Type of the multicast site."; "Type of the multicast site.";
} }
list multicast-gp-address-mapping { list multicast-gp-address-mapping {
key "id"; key "id";
description description
"List of Port to group mappings."; "List of port-to-group mappings.";
leaf id { leaf id {
type uint16; type uint16;
description description
"Unique identifier for the mapping."; "Unique identifier for the mapping.";
} }
leaf vlan-id { leaf vlan-id {
type uint32; type uint32;
mandatory true; mandatory true;
description description
"The VLAN ID of the multicast group."; "The VLAN ID of the multicast group.";
skipping to change at page 123, line 20 skipping to change at line 5604
} }
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
9. Security Considerations 9. Security Considerations
The YANG modules specified in this document defines schemas for data The YANG modules specified in this document define schemas for data
that are designed to be accessed via network management protocols that are designed to be accessed via network management protocols
such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF
layer is the secure transport layer, and the mandatory-to-implement layer is the secure transport layer, and the mandatory-to-implement
secure transport is Secure Shell (SSH) [RFC6242]. The lowest secure transport is Secure Shell (SSH) [RFC6242]. The lowest
RESTCONF layer is HTTPS, and the mandatory-to-implement secure RESTCONF layer is HTTPS, and the mandatory-to-implement secure
transport is TLS [RFC8446]. transport is TLS [RFC8446].
The Network Configuration Access Control Model (NACM) [RFC8341] The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content. RESTCONF protocol operations and content.
There are a number of data nodes defined in "ietf-l2vpn-ntw" and There are a number of data nodes defined in the "ietf-l2vpn-ntw" and
"ietf-ethernet-segment" YANG modules that are writable/creatable/ "ietf-ethernet-segment" YANG modules that are writable/creatable/
deletable (i.e., config true, which is the default). These data deletable (i.e., config true, which is the default). These data
nodes may be considered sensitive or vulnerable in some network nodes may be considered sensitive or vulnerable in some network
environments. Write operations (e.g., edit-config) and delete environments. Write operations (e.g., edit-config) and delete
operations to these data nodes without proper protection or operations to these data nodes without proper protection or
authentication can have a negative effect on network operations. authentication can have a negative effect on network operations.
These are the subtrees and data nodes and their sensitivity/ These are the subtrees and data nodes and their sensitivity/
vulnerability in the "ietf-l2vpn-ntw" and "ietf-ethernet-segment" vulnerability in the "ietf-l2vpn-ntw" and "ietf-ethernet-segment"
modules: modules:
* 'vpn-profiles': This container includes a set of sensitive data 'vpn-profiles': This container includes a set of sensitive data that
that influence how the L3VPN service is delivered. For example, influences how the L3VPN service is delivered. For example, an
an attacker who has access to these data nodes may be able to attacker who has access to these data nodes may be able to
manipulate routing policies, QoS policies, or encryption manipulate routing policies, QoS policies, or encryption
properties. These data nodes are defined with "nacm:default-deny- properties. These data nodes are defined with "nacm:default-deny-
write" tagging [RFC9181]. write" tagging [RFC9181].
* 'ethernet-segments' and 'vpn-services': An attacker who is able to 'ethernet-segments' and 'vpn-services': An attacker who is able to
access network nodes can undertake various attacks, such as access network nodes can undertake various attacks, such as
deleting a running L2VPN service, interrupting all the traffic of deleting a running L2VPN service, interrupting all the traffic of
a client. In addition, an attacker may modify the attributes of a a client. In addition, an attacker may modify the attributes of a
running service (e.g., QoS, bandwidth) or an ES, leading to running service (e.g., QoS, bandwidth) or an ES, leading to
malfunctioning of the service and therefore to SLA violations. In malfunctioning of the service and therefore to SLA violations. In
addition, an attacker could attempt to create an L2VPN service, addition, an attacker could attempt to create an L2VPN service,
add a new network access, or intercept/redirect the traffic to a add a new network access, or intercept/redirect the traffic to a
non-authorized node. In addition to using NACM to prevent non-authorized node. In addition to using NACM to prevent
authorized access, such activity can be detected by adequately authorized access, such activity can be detected by adequately
monitoring and tracking network configuration changes. monitoring and tracking network configuration changes.
Some of the readable data nodes in the "ietf-l2vpn-ntw" YANG module Some of the readable data nodes in the "ietf-l2vpn-ntw" YANG module
may be considered sensitive or vulnerable in some network may be considered sensitive or vulnerable in some network
environments. It is thus important to control read access (e.g., via environments. It is thus important to control read access (e.g., via
get, get-config, or notification) to these data nodes. These are the get, get-config, or notification) to these data nodes. These are the
subtrees and data nodes and their sensitivity/vulnerability: subtrees and data nodes and their sensitivity/vulnerability:
* 'customer-name' and 'ip-connection': An attacker can retrieve 'customer-name' and 'ip-connection': An attacker can retrieve
privacy-related information which can be used to track a customer. privacy-related information that can be used to track a customer.
Disclosing such information may be considered as a violation of Disclosing such information may be considered a violation of the
the customer-provider trust relationship. customer-provider trust relationship.
Both "iana-bgp-l2-encaps" and "iana-pseudowire-types" modules define Both "iana-bgp-l2-encaps" and "iana-pseudowire-types" modules define
YANG identities for encapsulation/pseudowires types. These YANG identities for encapsulation/pseudowires types. These
identities are intended to be referenced by other YANG modules, and identities are intended to be referenced by other YANG modules and by
by themselves do not expose any nodes which are writable, contain themselves do not expose any nodes that are writable or contain read-
read-only state, or RPCs. only state or RPCs.
10. IANA Considerations 10. IANA Considerations
10.1. Registering YANG Modules 10.1. Registering YANG Modules
This document requests IANA to register the following URIs in the IANA has registered the following URIs in the "ns" subregistry within
"ns" subregistry within the "IETF XML Registry" [RFC3688]: the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps URI: urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:iana-pseudowire-types URI: urn:ietf:params:xml:ns:yang:iana-pseudowire-types
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-ethernet-segment URI: urn:ietf:params:xml:ns:yang:ietf-ethernet-segment
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw URI: urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG modules in IANA has registered the following YANG modules in the "YANG Module
the "YANG Module Names" subregistry [RFC6020] within the "YANG Names" subregistry [RFC6020] within the "YANG Parameters" registry:
Parameters" registry:
name: iana-bgp-l2-encaps name: iana-bgp-l2-encaps
namespace: urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps namespace: urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps
maintained by IANA: Y maintained by IANA: Y
prefix: iana-bgp-l2-encaps prefix: iana-bgp-l2-encaps
reference: RFC XXXX reference: RFC 9291
name: iana-pseudowire-types name: iana-pseudowire-types
namespace: urn:ietf:params:xml:ns:yang:iana-pseudowire-types namespace: urn:ietf:params:xml:ns:yang:iana-pseudowire-types
maintained by IANA: Y maintained by IANA: Y
prefix: iana-pw-types prefix: iana-pw-types
reference: RFC XXXX reference: RFC 9291
name: ietf-ethernet-segment name: ietf-ethernet-segment
namespace: urn:ietf:params:xml:ns:yang:ietf-ethernet-segment namespace: urn:ietf:params:xml:ns:yang:ietf-ethernet-segment
maintained by IANA: N maintained by IANA: N
prefix: l2vpn-es prefix: l2vpn-es
reference: RFC XXXX reference: RFC 9291
name: ietf-l2vpn-ntw name: ietf-l2vpn-ntw
namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw
maintained by IANA: N maintained by IANA: N
prefix: l2vpn-ntw prefix: l2vpn-ntw
reference: RFC XXXX reference: RFC 9291
10.2. BGP Layer 2 Encapsulation Types 10.2. BGP Layer 2 Encapsulation Types
This document defines the initial version of the IANA-maintained This document defines the initial version of the IANA-maintained
"iana-bgp-l2-encaps" YANG module (Section 8.1). IANA is requested to "iana-bgp-l2-encaps" YANG module (Section 8.1). IANA has added this
add this note to the registry: note to the "YANG Module Names" registry:
BGP Layer 2 encapsulation types must not be directly added to the BGP Layer 2 encapsulation types must not be directly added to the
"iana-bgp-l2-encaps" YANG module. They must instead be added to "iana-bgp-l2-encaps" YANG module. They must instead be added to
the "BGP Layer 2 Encapsulation Types" registry [IANA-BGP-L2]. the "BGP Layer 2 Encapsulation Types" registry at [IANA-BGP-L2].
When a Layer 2 encapsulation type is added to the "BGP Layer 2 When a Layer 2 encapsulation type is added to the "BGP Layer 2
Encapsulation Types" registry, a new "identity" statement must be Encapsulation Types" registry, a new "identity" statement must be
added to the "iana-bgp-l2-encaps" YANG module. The name of the added to the "iana-bgp-l2-encaps" YANG module. The name of the
"identity" is a lower-case version of the encapsulation name provided "identity" is a lower-case version of the encapsulation name provided
in the description. The "identity" statement should have the in the description. The "identity" statement should have the
following sub-statements defined: following sub-statements defined:
"base": Contains 'bgp-l2-encaps-type'. "base": Contains 'bgp-l2-encaps-type'.
skipping to change at page 126, line 35 skipping to change at line 5744
"reference": Replicates the reference from the registry with the "reference": Replicates the reference from the registry with the
title of the document added. title of the document added.
Unassigned or reserved values are not present in the module. Unassigned or reserved values are not present in the module.
When the "iana-bgp-l2-encaps" YANG module is updated, a new When the "iana-bgp-l2-encaps" YANG module is updated, a new
"revision" statement with a unique revision date must be added in "revision" statement with a unique revision date must be added in
front of the existing revision statements. front of the existing revision statements.
IANA is requested to add this note to [IANA-BGP-L2]: IANA has added this note to [IANA-BGP-L2]:
When this registry is modified, the YANG module "iana-bgp- When this registry is modified, the YANG module "iana-bgp-
l2-encaps" must be updated as defined in RFCXXXX. l2-encaps" must be updated as defined in RFC 9291.
10.3. Pseudowire Types 10.3. Pseudowire Types
This document defines the initial version of the IANA-maintained This document defines the initial version of the IANA-maintained
"iana-pseudowire-types" YANG module (Section 8.2). IANA is requested "iana-pseudowire-types" YANG module (Section 8.2). IANA has added
to add this note to the registry: this note to the "YANG Module Names" registry:
MPLS pseudowire types must not be directly added to the "iana-bgp- MPLS pseudowire types must not be directly added to the "iana-
l2-encaps" YANG module. They must instead be added to the "MPLS pseudowire-types" YANG module. They must instead be added to the
Pseudowire Types" registry [IANA-PW-Types]. "MPLS Pseudowire Types" registry at [IANA-PW-TYPES].
When a pseudowire type is added to the "iana-pseudowire-types" When a pseudowire type is added to the "iana-pseudowire-types"
registry, a new "identity" statement must be added to the "iana- registry, a new "identity" statement must be added to the "iana-
pseudowire-types" YANG module. The name of the "identity" is a pseudowire-types" YANG module. The name of the "identity" is a
lower-case version of the encapsulation name provided in the lower-case version of the encapsulation name provided in the
description. The "identity" statement should have the following sub- description. The "identity" statement should have the following sub-
statements defined: statements defined:
"base": Contains 'iana-pw-types'. "base": Contains 'iana-pw-types'.
"description": Replicates the description from the registry. "description": Replicates the description from the registry.
"reference": Replicates the reference from the registry with the "reference": Replicates the reference from the registry with the
title of the document added title of the document added.
Unassigned or reserved values are not present in the module. Unassigned or reserved values are not present in the module.
When the "iana-pseudowire-types" YANG module is updated, a new When the "iana-pseudowire-types" YANG module is updated, a new
"revision" statement with a unique revision date must be added in "revision" statement with a unique revision date must be added in
front of the existing revision statements. front of the existing revision statements.
IANA is requested to add this note to [IANA-PW-Types]: IANA has added this note to [IANA-PW-TYPES]:
When this registry is modified, the YANG module "iana-pseudowire- When this registry is modified, the YANG module "iana-pseudowire-
types" must be updated as defined in RFCXXXX. types" must be updated as defined in RFC 9291.
11. References 11. References
11.1. Normative References 11.1. Normative References
[IANA-BGP-L2] [IANA-BGP-L2]
IANA, "BGP Layer 2 Encapsulation Types", IANA, "BGP Layer 2 Encapsulation Types",
<https://www.iana.org/assignments/bgp-parameters/bgp- <https://www.iana.org/assignments/bgp-parameters>.
parameters.xhtml#bgp-l2-encapsulation-types-registry>.
[IANA-PW-Types] [IANA-PW-TYPES]
IANA, "MPLS Pseudowire Types Registry", IANA, "MPLS Pseudowire Types Registry",
<http://www.iana.org/assignments/pwe3-parameters/ <http://www.iana.org/assignments/pwe3-parameters/>.
pwe3-parameters.xhtml#pwe3-parameters-2>.
[IEEE-802-1ag] [IEEE-802-1ag]
IEEE, "802.1ag - 2007 - IEEE Standard for Local and IEEE, "IEEE Standard for Local and Metropolitan Area
Metropolitan Area Networks - Virtual Bridged Local Area Networks - Virtual Bridged Local Area Networks Amendment
Networks Amendment 5: Connectivity Fault Management", 5: Connectivity Fault Management",
2007, <DOI 10.1109/IEEESTD.2007.4431836>. DOI 10.1109/IEEESTD.2007.4431836, IEEE Std 802.1ag-2007,
December 2007,
<https://doi.org/10.1109/IEEESTD.2007.4431836>.
[IEEE802.1Qcp-2018] [IEEE802.1Qcp]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks--Bridges and Bridged Networks--Amendment 30: YANG networks--Bridges and Bridged Networks--Amendment 30: YANG
Data Model", September 2018, Data Model", DOI 10.1109/IEEESTD.2018.8467507, IEEE Std
<https://ieeexplore.ieee.org/document/8467507>. 802.1Qcp-2018, September 2018,
<https://doi.org/10.1109/IEEESTD.2018.8467507>.
[ITU-T-Y-1731] [ITU-T-Y-1731]
Union, I. T., "Operations, administration and maintenance ITU-T, "Operation, administration and maintenance (OAM)
(OAM) functions and mechanisms for Ethernet-based functions and mechanisms for Ethernet-based networks",
networks", August 2015, ITU-T Recommendation G.8013/Y.1731, August 2015,
<https://www.itu.int/rec/T-REC-Y.1731/en>. <https://www.itu.int/rec/T-REC-Y.1731/en>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026, Private Network (VPN) Terminology", RFC 4026,
DOI 10.17487/RFC4026, March 2005, DOI 10.17487/RFC4026, March 2005,
<https://www.rfc-editor.org/info/rfc4026>. <https://www.rfc-editor.org/info/rfc4026>.
skipping to change at page 131, line 5 skipping to change at line 5946
RFC 8584, DOI 10.17487/RFC8584, April 2019, RFC 8584, DOI 10.17487/RFC8584, April 2019,
<https://www.rfc-editor.org/info/rfc8584>. <https://www.rfc-editor.org/info/rfc8584>.
[RFC9181] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., [RFC9181] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M.,
Ed., and Q. Wu, "A Common YANG Data Model for Layer 2 and Ed., and Q. Wu, "A Common YANG Data Model for Layer 2 and
Layer 3 VPNs", RFC 9181, DOI 10.17487/RFC9181, February Layer 3 VPNs", RFC 9181, DOI 10.17487/RFC9181, February
2022, <https://www.rfc-editor.org/info/rfc9181>. 2022, <https://www.rfc-editor.org/info/rfc9181>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-bess-evpn-pref-df] [BGP-YANG-MODEL]
Rabadan, J., Sathappan, S., Przygienda, T., Lin, W.,
Drake, J., Sajassi, A., and S. Mohanty, "Preference-based
EVPN DF Election", Work in Progress, Internet-Draft,
draft-ietf-bess-evpn-pref-df-08, 23 September 2021,
<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-
pref-df-08.txt>.
[I-D.ietf-bess-evpn-yang]
Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K.,
and J. Rabadan, "Yang Data Model for EVPN", Work in
Progress, Internet-Draft, draft-ietf-bess-evpn-yang-07, 11
March 2019, <https://www.ietf.org/archive/id/draft-ietf-
bess-evpn-yang-07.txt>.
[I-D.ietf-idr-bgp-model]
Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP
YANG Model for Service Provider Networks", Work in YANG Model for Service Provider Networks", Work in
Progress, Internet-Draft, draft-ietf-idr-bgp-model-13, 6 Progress, Internet-Draft, draft-ietf-idr-bgp-model-14, 3
March 2022, <https://www.ietf.org/archive/id/draft-ietf- July 2022, <https://datatracker.ietf.org/doc/html/draft-
idr-bgp-model-13.txt>. ietf-idr-bgp-model-14>.
[I-D.ietf-opsawg-sap]
Boucadair, M., Dios, O. G. D., Barguil, S., Wu, Q., and V.
Lopez, "A Network YANG Model for Service Attachment Points
(SAPs)", Work in Progress, Internet-Draft, draft-ietf-
opsawg-sap-07, 20 May 2022,
<https://www.ietf.org/archive/id/draft-ietf-opsawg-sap-
07.txt>.
[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", Work in Progress, Internet-Draft, draft-ietf-
teas-enhanced-vpn-10, 6 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-teas-enhanced-
vpn-10.txt>.
[I-D.ietf-teas-ietf-network-slices] [EVPN-PERF-DF]
Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, Rabadan, J., Ed., Sathappan, S., Lin, W., Drake, J., and
K., Contreras, L. M., and J. Tantsura, "Framework for IETF A. Sajassi, "Preference-based EVPN DF Election", Work in
Network Slices", Work in Progress, Internet-Draft, draft- Progress, Internet-Draft, draft-ietf-bess-evpn-pref-df-10,
ietf-teas-ietf-network-slices-10, 27 March 2022, 2 September 2022, <https://datatracker.ietf.org/doc/html/
<https://www.ietf.org/archive/id/draft-ietf-teas-ietf- draft-ietf-bess-evpn-pref-df-10>.
network-slices-10.txt>.
[I-D.ietf-teas-te-service-mapping-yang] [EVPN-YANG]
Lee, Y., Dhody, D., Fioccola, G., Wu, Q., Ceccarelli, D., Brissette, P., Ed., Shah, H., Ed., Chen, I., Ed., Hussain,
and J. Tantsura, "Traffic Engineering (TE) and Service I., Ed., Tiruveedhula, K., Ed., and J. Rabadan, Ed., "Yang
Mapping YANG Model", Work in Progress, Internet-Draft, Data Model for EVPN", Work in Progress, Internet-Draft,
draft-ietf-teas-te-service-mapping-yang-10, 7 March 2022, draft-ietf-bess-evpn-yang-07, 11 March 2019,
<https://www.ietf.org/archive/id/draft-ietf-teas-te- <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
service-mapping-yang-10.txt>. evpn-yang-07>.
[IEEE-802-1ah] [IEEE-802-1ah]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks -- Virtual Bridged Local Area Networks Amendment networks -- Virtual Bridged Local Area Networks Amendment
7: Provider Backbone Bridges", IEEE Std 801.3AH-2008, 7: Provider Backbone Bridges", IEEE Std 801.3AH-2008,
2008, August 2008,
<https://standards.ieee.org/standard/802_1ah-2008.html>. <https://standards.ieee.org/standard/802_1ah-2008.html>.
[IEEE-802-3ah] [IEEE-802-3ah]
IEEE, "802.3ah - 2004 - IEEE Standard for Information IEEE, "IEEE Standard for Information technology-- Local
technology-- Local and metropolitan area networks-- Part and metropolitan area networks-- Part 3: CSMA/CD Access
3: CSMA/CD Access Method and Physical Layer Specifications Method and Physical Layer Specifications Amendment: Media
Amendment: Media Access Control Parameters, Physical Access Control Parameters, Physical Layers, and Management
Layers, and Management Parameters for Subscriber Access Parameters for Subscriber Access Networks",
Networks", IEEE Std 802.3AH-2004, 2004, <DOI 10.1109/ DOI 10.1109/IEEESTD.2004.94617, IEEE Std 802.3AH-2004,
IEEESTD.2004.94617>. September 2004,
<https://doi.org/10.1109/IEEESTD.2004.94617>.
[IEEE802.1AX] [IEEE802.1AX]
"Link Aggregation", IEEE Std 802.1AX-2020, 2020. IEEE, "IEEE Standard for Local and Metropolitan Area
Networks--Link Aggregation",
DOI 10.1109/IEEESTD.2020.9105034, IEEE Std 802.1AX-2020,
May 2020, <https://doi.org/10.1109/IEEESTD.2020.9105034>.
[IEEE802.1Q] [IEEE802.1Q]
"Bridges and Bridged Networks", IEEE Std 802.1Q-2018, 6 IEEE, "IEEE Standard for Local and Metropolitan Area
July 2018, <https://ieeexplore.ieee.org/document/8403927>. Network--Bridges and Bridged Networks",
DOI 10.1109/IEEESTD.2018.8403927, IEEE Std 802.1Q-2018,
July 2018, <https://doi.org/10.1109/IEEESTD.2018.8403927>.
[MFA] "The Use of Virtual Trunks for ATM/MPLS Control Plane [IETF-NET-SLICES]
Interworking Specification", MFA Forum 9.0.0 , February Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S.,
2006. Makhijani, K., Contreras, L. M., and J. Tantsura,
"Framework for IETF Network Slices", Work in Progress,
Internet-Draft, draft-ietf-teas-ietf-network-slices-14, 3
August 2022, <https://datatracker.ietf.org/doc/html/draft-
ietf-teas-ietf-network-slices-14>.
[MFA] MFA Forum Technical Committee, "The Use of Virtual Trunks
for ATM/MPLS Control Plane Interworking Specification",
MFA Forum 9.0.0, February 2006.
[PYANG] "pyang", November 2020, [PYANG] "pyang", November 2020,
<https://github.com/mbj4668/pyang>. <https://github.com/mbj4668/pyang>.
[RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header [RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header
Compression", RFC 2507, DOI 10.17487/RFC2507, February Compression", RFC 2507, DOI 10.17487/RFC2507, February
1999, <https://www.rfc-editor.org/info/rfc2507>. 1999, <https://www.rfc-editor.org/info/rfc2507>.
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, Headers for Low-Speed Serial Links", RFC 2508,
skipping to change at page 136, line 25 skipping to change at line 6185
[RFC8960] Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A [RFC8960] Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A
YANG Data Model for MPLS Base", RFC 8960, YANG Data Model for MPLS Base", RFC 8960,
DOI 10.17487/RFC8960, December 2020, DOI 10.17487/RFC8960, December 2020,
<https://www.rfc-editor.org/info/rfc8960>. <https://www.rfc-editor.org/info/rfc8960>.
[RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and
L. Geng, "A Framework for Automating Service and Network L. Geng, "A Framework for Automating Service and Network
Management with YANG", RFC 8969, DOI 10.17487/RFC8969, Management with YANG", RFC 8969, DOI 10.17487/RFC8969,
January 2021, <https://www.rfc-editor.org/info/rfc8969>. January 2021, <https://www.rfc-editor.org/info/rfc8969>.
[TE-SERVICE-MAPPING]
Lee, Y., Ed., Dhody, D., Ed., Fioccola, G., Wu, Q., Ed.,
Ceccarelli, D., and J. Tantsura, "Traffic Engineering (TE)
and Service Mapping YANG Data Model", Work in Progress,
Internet-Draft, draft-ietf-teas-te-service-mapping-yang-
11, 11 July 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-teas-te-service-mapping-yang-11>.
[VPN+-FRAMEWORK]
Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
Framework for Enhanced Virtual Private Network (VPN+)
Services", Work in Progress, Internet-Draft, draft-ietf-
teas-enhanced-vpn-10, 6 March 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
enhanced-vpn-10>.
[YANG-SAPS]
Boucadair, M., Ed., Gonzalez de Dios, O., Barguil, S., Wu,
Q., and V. Lopez, "A YANG Network Model for Service
Attachment Points (SAPs)", Work in Progress, Internet-
Draft, draft-ietf-opsawg-sap-09, 28 July 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
sap-09>.
Appendix A. Examples Appendix A. Examples
This section includes a non-exhaustive list of examples to illustrate This section includes a non-exhaustive list of examples to illustrate
the use of the L2NM. the use of the L2NM.
In the following subsections, only the content of the message bodies In the following subsections, only the content of the message bodies
is shown using JSON notations [RFC7951]. is shown using JSON notations [RFC7951].
The examples use the folding defined in [RFC8792] for long lines. The examples use folding as defined in [RFC8792] for long lines.
A.1. BGP-based VPLS A.1. BGP-Based VPLS
This section provides an example to illustrate how the L2NM can be This section provides an example to illustrate how the L2NM can be
used to manage BGP-based VPLS. We consider the sample VPLS service used to manage BGP-based VPLS. We consider the sample VPLS service
delivered using the architecture depicted in Figure 23. In delivered using the architecture depicted in Figure 23. In
accordance with [RFC4761], we assume that a full mesh is established accordance with [RFC4761], we assume that a full mesh is established
between all PEs. The details about such full mesh are not detailed between all PEs. The details about such full mesh are not detailed
here. here.
+-----+ +--------------+ +-----+ +-----+ +--------------+ +-----+
+----+ | PE1 |===| |===| PE3 | +----+ +----+ | PE1 |===| |===| PE3 | +----+
| CE1+-------+ | | | | +-------+ CE3| | CE1+-------+ | | | | +-------+ CE3|
+----+ +-----+ | | +-----+ +----+ +----+ +-----+ | | +-----+ +----+
| Core | | Core |
+----+ +-----+ | | +-----+ +----+ +----+ +-----+ | | +-----+ +----+
|CE2 +-------+ | | | | +-------+ CE4| |CE2 +-------+ | | | | +-------+ CE4|
+----+ | PE2 |===| |===| PE4 | +----+ +----+ | PE2 |===| |===| PE4 | +----+
+-----+ +--------------+ +-----+ +-----+ +--------------+ +-----+
Figure 23: An Example of VPLS Figure 23: An Example of VPLS
Figure 24 show an example of a message body used to configure a VPLS Figure 24 shows an example of a message body used to configure a VPLS
instance using the L2NM. In this example, BGP is used for both auto- instance using the L2NM. In this example, BGP is used for both auto-
discovery and signaling. The 'signaling-type' data node is set to discovery and signaling. The 'signaling-type' data node is set to
'vpn-common:bgp-signaling'. 'vpn-common:bgp-signaling'.
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-l2vpn-ntw:l2vpn-ntw": {
"vpn-services": {
"vpn-service": [
{
"vpn-id": "vpls7714825356",
"vpn-description": "Sample BGP-based VPLS",
"customer-name": "customer-7714825356",
"vpn-type": "ietf-vpn-common:vpls",
"bgp-ad-enabled": true,
"signaling-type": "ietf-vpn-common:bgp-signaling",
"global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile",
"local-autonomous-system": 65535,
"svc-mtu": 1518,
"rd-suffix": 1,
"vpn-target": [
{
"id": 1,
"route-targets": [
{
"route-target": "0:65535:1"
}
],
"route-target-type": "both"
}
]
} {
] "ietf-l2vpn-ntw:l2vpn-ntw": {
}, "vpn-services": {
"vpn-nodes": { "vpn-service": [
"vpn-node": [ {
{ "vpn-id": "vpls7714825356",
"vpn-node-id": "pe1", "vpn-description": "Sample BGP-based VPLS",
"ne-id": "198.51.100.1", "customer-name": "customer-7714825356",
"active-global-parameters-profiles": { "vpn-type": "ietf-vpn-common:vpls",
"global-parameters-profile": [ "bgp-ad-enabled": true,
{ "signaling-type": "ietf-vpn-common:bgp-signaling",
"profile-id": "simple-profile" "global-parameters-profiles": {
} "global-parameters-profile": [
] {
}, "profile-id": "simple-profile",
"bgp-auto-discovery": { "local-autonomous-system": 65535,
"vpn-id": "1" "svc-mtu": 1518,
}, "rd-suffix": 1,
"signaling-option": { "vpn-target": [
"pw-encapsulation-type": "iana-bgp-l2-encaps:ethernet\ {
-tagged-mode", "id": 1,
"vpls-instance": { "route-targets": [
"vpls-edge-id": 1, {
"vpls-edge-id-range": 100 "route-target": "0:65535:1"
} }
}, ],
"vpn-network-accesses": { "route-target-type": "both"
"vpn-network-access": [ }
{ ]
"id": "1/1/1.1", }
"interface-id": "1/1/1", ]
"description": "Interface to CE1", },
"active-vpn-node-profile": "simple-profile", "vpn-nodes": {
"status": { "vpn-node": [
"admin-status": { {
"status": "ietf-vpn-common:admin-up" "vpn-node-id": "pe1",
} "ne-id": "198.51.100.1",
}, "active-global-parameters-profiles": {
"connection": { "global-parameters-profile": [
"encapsulation": { {
"encap-type": "ietf-vpn-common:dot1q", "profile-id": "simple-profile"
"dot1q": { }
"cvlan-id": 1 ]
} },
} "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-accesses": {
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE1",
"active-vpn-node-profile": "simple-profile",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
}
},
"connection": {
"encapsulation": {
"encap-type": "ietf-vpn-common:dot1q",
"dot1q": {
"cvlan-id": 1
}
}
}
}
]
}
},
{
"vpn-node-id": "pe2",
"ne-id": "198.51.100.2",
"active-global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"bgp-auto-discovery": {
"vpn-id": "1"
},
"signaling-option": {
"pw-encapsulation-type": "iana-bgp-l2-encaps:\
ethernet-tagged-mode",
"vpls-instance": {
"vpls-edge-id": 2,
"vpls-edge-id-range": 100
}
},
"vpn-network-accesses": {
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE2",
"active-vpn-node-profile": "simple-profile",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
}
},
"connection": {
"encapsulation": {
"encap-type": "ietf-vpn-common:dot1q",
"dot1q": {
"cvlan-id": 1
}
}
}
}
]
}
},
{
"vpn-node-id": "pe3",
"ne-id": "198.51.100.3",
"active-global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"bgp-auto-discovery": {
"vpn-id": "1"
},
"signaling-option": {
"pw-encapsulation-type": "iana-bgp-l2-encaps:\
ethernet-tagged-mode",
"vpls-instance": {
"vpls-edge-id": 3,
"vpls-edge-id-range": 100
}
},
"vpn-network-accesses": {
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE3",
"active-vpn-node-profile": "simple-profile",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
}
},
"connection": {
"encapsulation": {
"encap-type": "ietf-vpn-common:dot1q",
"dot1q": {
"cvlan-id": 1
}
}
}
}
]
}
},
{
"vpn-node-id": "pe4",
"ne-id": "198.51.100.4",
"active-global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"bgp-auto-discovery": {
"vpn-id": "1"
},
"signaling-option": {
"pw-encapsulation-type": "iana-bgp-l2-encaps:\
ethernet-tagged-mode",
"vpls-instance": {
"vpls-edge-id": 4,
"vpls-edge-id-range": 100
}
},
"vpn-network-accesses": {
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE4",
"active-vpn-node-profile": "simple-profile",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
}
},
"connection": {
"encapsulation": {
"encap-type": "ietf-vpn-common:dot1q",
"dot1q": {
"cvlan-id": 1
}
}
}
}
]
}
}
]
}
}
]
}
}
}
} Figure 24: An Example of an L2NM Message Body to Configure a BGP-
}, Based VPLS
{
"vpn-node-id": "pe2",
"ne-id": "198.51.100.2",
"active-global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"bgp-auto-discovery": {
"vpn-id": "1"
},
"signaling-option": {
"pw-encapsulation-type": "iana-bgp-l2-encaps:ethernet\
-tagged-mode",
"vpls-instance": {
"vpls-edge-id": 2,
"vpls-edge-id-range": 100
}
},
"vpn-network-accesses": {
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE2",
"active-vpn-node-profile": "simple-profile",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
}
},
"connection": {
"encapsulation": {
"encap-type": "ietf-vpn-common:dot1q",
"dot1q": {
"cvlan-id": 1
}
}
}
}
]
}
},
{
"vpn-node-id": "pe3",
"ne-id": "198.51.100.3",
"active-global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"bgp-auto-discovery": {
"vpn-id": "1"
},
"signaling-option": {
"pw-encapsulation-type": "iana-bgp-l2-encaps:ethernet\
-tagged-mode",
"vpls-instance": {
"vpls-edge-id": 3,
"vpls-edge-id-range": 100
}
},
"vpn-network-accesses": {
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE3",
"active-vpn-node-profile": "simple-profile",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
}
},
"connection": {
"encapsulation": {
"encap-type": "ietf-vpn-common:dot1q",
"dot1q": {
"cvlan-id": 1
}
}
}
}
]
}
},
{
"vpn-node-id": "pe4",
"ne-id": "198.51.100.4",
"active-global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"bgp-auto-discovery": {
"vpn-id": "1"
},
"signaling-option": {
"pw-encapsulation-type": "iana-bgp-l2-encaps:ethernet\
-tagged-mode",
"vpls-instance": {
"vpls-edge-id": 4,
"vpls-edge-id-range": 100
}
},
"vpn-network-accesses": {
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE4",
"active-vpn-node-profile": "simple-profile",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
}
},
"connection": {
"encapsulation": {
"encap-type": "ietf-vpn-common:dot1q",
"dot1q": {
"cvlan-id": 1
}
}
}
}
]
}
}
]
}
}
]
}
}
}
Figure 24: Example of L2NM Message Body to Configure a BGP-based VPLS
A.2. BGP-based VPWS with LDP Signaling A.2. BGP-Based VPWS with LDP Signaling
Let's consider the simple architecture depicted in Figure 25 to offer 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 a VPWS between CE1 and CE2. The service uses BGP for auto-discovery
and LDP for signaling. and LDP for signaling.
+-----+ +--------------+ +-----+ +-----+ +--------------+ +-----+
+----+ | PE1 |===| |===| PE2 | +----+ +----+ | PE1 |===| |===| PE2 | +----+
| CE1+-------+ | | Core | | +-------+ CE2| | CE1+-------+ | | Core | | +-------+ CE2|
+----+ +-----+ +--------------+ +-----+ +----+ +----+ +-----+ +--------------+ +-----+ +----+
site1 site2 site1 site2
skipping to change at page 145, line 4 skipping to change at line 6612
] ]
} }
} }
] ]
} }
} }
] ]
} }
} }
} }
Figure 26: Example of L2NM Message Body to Configure a BGP-based
VPWS with LDP Signaling
A.3. LDP-based VPLS Figure 26: An Example of an L2NM Message Body to Configure a BGP-
Based VPWS with LDP Signaling
This section provides an example to illustrate how the L2NM can be A.3. LDP-Based VPLS
This section provides an example that illustrates how the L2NM can be
used to manage a VPLS with LDP signaling. The connectivity between used to manage a VPLS with LDP signaling. The connectivity between
the CE and the PE is direct using Dot1q encapsulation [IEEE802.1Q]. the CE and the PE is direct using Dot1q encapsulation [IEEE802.1Q].
We consider the sample service delivered using the architecture We consider the sample service delivered using the architecture
depicted in Figure 27. depicted in Figure 27.
+---------- VPLS "1543" ----------+ +---------- VPLS "1543" ----------+
+-----+ +--------------+ +-----+ +-----+ +--------------+ +-----+
+----+ | PE1 |===| |===| PE2 | +----+ +----+ | PE1 |===| |===| PE2 | +----+
| CE1 +-----+"450"| | MPLS | |"451"+-------+ CE2| | CE1 +-----+"450"| | MPLS | |"451"+-------+ CE2|
+----+ +-----+ | | +-----+ +----+ +----+ +-----+ | | +-----+ +----+
| Core | | Core |
+--------------+ +--------------+
Figure 27: An Example of VPLS topology Figure 27: An Example of VPLS Topology
Figure 28 shows how the L2NM is used to instruct both PE1 and PE2 to 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 use the targeted LDP session between them to establish the VPLS
"1543" between the ends. A single VPN service is created for this "1543" between the ends. A single VPN service is created for this
purpose. Additionally, two VPN Nodes and each with a corresponding purpose. Additionally, two VPN Nodes that each have corresponding
VPN network access is also created. VPN network access are also created.
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
{ {
"ietf-l2vpn-ntw:l2vpn-ntw": { "ietf-l2vpn-ntw:l2vpn-ntw": {
"vpn-services": { "vpn-services": {
"vpn-service": [ "vpn-service": [
{ {
"vpn-id": "450", "vpn-id": "450",
"vpn-name": "CORPO-EXAMPLE", "vpn-name": "CORPO-EXAMPLE",
"vpn-description": "SEDE_CENTRO_450", "vpn-description": "SEDE_CENTRO_450",
"customer-name": "EXAMPLE", "customer-name": "EXAMPLE",
"vpn-type": "ietf-vpn-common:vpls", "vpn-type": "ietf-vpn-common:vpls",
"vpn-service-topology": "ietf-vpn-common:hub-spoke", "vpn-service-topology": "ietf-vpn-common:hub-spoke",
"bgp-ad-enabled": false, "bgp-ad-enabled": false,
"signaling-type": "ietf-vpn-common:ldp-signaling", "signaling-type": "ietf-vpn-common:ldp-signaling",
"global-parameters-profiles": { "global-parameters-profiles": {
"global-parameters-profile": [ "global-parameters-profile": [
{ {
"profile-id": "simple-profile", "profile-id": "simple-profile",
"ce-vlan-preservation": true, "ce-vlan-preservation": true,
"ce-vlan-cos-preservation": true "ce-vlan-cos-preservation": true
} }
] ]
}, },
"vpn-nodes": { "vpn-nodes": {
"vpn-node": [ "vpn-node": [
{ {
"vpn-node-id": "450", "vpn-node-id": "450",
"description": "SEDE_CENTRO_450", "description": "SEDE_CENTRO_450",
"ne-id": "2001:db8:5::1", "ne-id": "2001:db8:5::1",
"role": "ietf-vpn-common:hub-role", "role": "ietf-vpn-common:hub-role",
"status": { "status": {
"admin-status": { "admin-status": {
"status": "ietf-vpn-common:admin-up" "status": "ietf-vpn-common:admin-up"
}
},
"active-global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
} }
] },
}, "active-global-parameters-profiles": {
"signaling-option": { "global-parameters-profile": [
"ldp-or-l2tp": {
"t-ldp-pw-type": "vpls-type",
"pw-peer-list": [
{ {
"peer-addr": "2001:db8:50::1", "profile-id": "simple-profile"
"vc-id": "1543"
} }
] ]
} },
}, "signaling-option": {
"vpn-network-accesses": { "ldp-or-l2tp": {
"vpn-network-access": [ "t-ldp-pw-type": "vpls-type",
{ "pw-peer-list": [
"id": "4508671287", {
"description": "VPN_450_SNA", "peer-addr": "2001:db8:50::1",
"interface-id": "gigabithethernet0/0/1", "vc-id": "1543"
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
} }
}, ]
"connection": { }
"l2-termination-point": "550", },
"encapsulation": { "vpn-network-accesses": {
"encap-type": "ietf-vpn-common:dot1q", "vpn-network-access": [
"dot1q": { {
"tag-type": "ietf-vpn-common:c-vlan", "id": "4508671287",
"cvlan-id": 550 "description": "VPN_450_SNA",
"interface-id": "gigabithethernet0/0/1",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
} }
}
},
"service": {
"mtu": 1550,
"svc-pe-to-ce-bandwidth": {
"pe-to-ce-bandwidth": [
{
"bw-type": "ietf-vpn-common:bw-per-port",
"cir": "20480000"
}
]
}, },
"svc-ce-to-pe-bandwidth": { "connection": {
"ce-to-pe-bandwidth": [ "l2-termination-point": "550",
{ "encapsulation": {
"bw-type": "ietf-vpn-common:bw-per-port", "encap-type": "ietf-vpn-common:dot1q",
"cir": "20480000" "dot1q": {
"tag-type": "ietf-vpn-common:c-vlan",
"cvlan-id": 550
} }
] }
}, },
"qos": { "service": {
"qos-profile": { "mtu": 1550,
"qos-profile": [ "svc-pe-to-ce-bandwidth": {
"pe-to-ce-bandwidth": [
{ {
"profile": "QoS_Profile_A", "bw-type": "ietf-vpn-common:\
"direction": "ietf-vpn-common:both" bw-per-port",
"cir": "20480000"
}
]
},
"svc-ce-to-pe-bandwidth": {
"ce-to-pe-bandwidth": [
{
"bw-type": "ietf-vpn-common:\
bw-per-port",
"cir": "20480000"
} }
] ]
},
"qos": {
"qos-profile": {
"qos-profile": [
{
"profile": "QoS_Profile_A",
"direction": "ietf-vpn-common:both"
}
]
}
} }
} }
} }
} ]
]
}
},
{
"vpn-node-id": "451",
"description": "SEDE_CHAPINERO_451",
"ne-id": "2001:db8:50::1",
"role": "ietf-vpn-common:spoke-role",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
} }
}, },
"active-global-parameters-profiles": { {
"global-parameters-profile": [ "vpn-node-id": "451",
{ "description": "SEDE_CHAPINERO_451",
"profile-id": "simple-profile" "ne-id": "2001:db8:50::1",
"role": "ietf-vpn-common:spoke-role",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
} }
] },
}, "active-global-parameters-profiles": {
"signaling-option": { "global-parameters-profile": [
"ldp-or-l2tp": {
"t-ldp-pw-type": "vpls-type",
"pw-peer-list": [
{ {
"peer-addr": "2001:db8:5::1", "profile-id": "simple-profile"
"vc-id": "1543"
} }
] ]
} },
}, "signaling-option": {
"vpn-network-accesses": { "ldp-or-l2tp": {
"vpn-network-access": [ "t-ldp-pw-type": "vpls-type",
{ "pw-peer-list": [
"id": "4508671288", {
"description": "VPN_450_SNA", "peer-addr": "2001:db8:5::1",
"interface-id": "gigabithethernet0/0/1", "vc-id": "1543"
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
} }
}, ]
"connection": { }
"l2-termination-point": "550", },
"encapsulation": { "vpn-network-accesses": {
"encap-type": "ietf-vpn-common:dot1q", "vpn-network-access": [
"dot1q": { {
"tag-type": "ietf-vpn-common:c-vlan", "id": "4508671288",
"cvlan-id": 550 "description": "VPN_450_SNA",
"interface-id": "gigabithethernet0/0/1",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
} }
}
},
"service": {
"mtu": 1550,
"svc-pe-to-ce-bandwidth": {
"pe-to-ce-bandwidth": [
{
"bw-type": "ietf-vpn-common:bw-per-port",
"cir": "20480000"
}
]
}, },
"svc-ce-to-pe-bandwidth": { "connection": {
"ce-to-pe-bandwidth": [ "l2-termination-point": "550",
{ "encapsulation": {
"bw-type": "ietf-vpn-common:bw-per-port", "encap-type": "ietf-vpn-common:dot1q",
"cir": "20480000" "dot1q": {
"tag-type": "ietf-vpn-common:c-vlan",
"cvlan-id": 550
} }
] }
}, },
"qos": { "service": {
"qos-profile": { "mtu": 1550,
"qos-profile": [ "svc-pe-to-ce-bandwidth": {
"pe-to-ce-bandwidth": [
{ {
"profile": "QoS_Profile_A", "bw-type": "ietf-vpn-common:\
"direction": "ietf-vpn-common:both" bw-per-port",
"cir": "20480000"
}
]
},
"svc-ce-to-pe-bandwidth": {
"ce-to-pe-bandwidth": [
{
"bw-type": "ietf-vpn-common:\
bw-per-port",
"cir": "20480000"
} }
] ]
},
"qos": {
"qos-profile": {
"qos-profile": [
{
"profile": "QoS_Profile_A",
"direction": "ietf-vpn-common:both"
}
]
}
} }
} }
} }
} ]
] }
} }
} ]
] }
} }
} ]
] }
} }
} }
}
Figure 28: Example of L2NM Message Body for LDP-based VPLS Figure 28: An Example of an L2NM Message Body for LDP-Based VPLS
A.4. VPWS-EVPN Service Instance A.4. VPWS-EVPN Service Instance
Figure 29 depicts a sample architecture to offer VPWS-EVPN service Figure 29 depicts a sample architecture to offer VPWS-EVPN service
between CE1 and CE2. Both CEs are multi-homed. BGP sessions are between CE1 and CE2. Both CEs are multihomed. BGP sessions are
maintained between these PEs as per [RFC8214]. In this EVPN maintained between these PEs as per [RFC8214]. In this EVPN
instance, an All-Active redundancy mode is used. instance, an All-Active redundancy mode is used.
|<-------- EVPN Instance --------->| |<-------- EVPN Instance --------->|
| | | |
ESI1 V V ESI2 ESI1 V V ESI2
| +-----+ +--------------+ +-----+ | | +-----+ +--------------+ +-----+ |
+----+ | | PE1 |===| |===| PE3 | | +----+ +----+ | | PE1 |===| |===| PE3 | | +----+
| +-------+ | | | | +-------+ | | +-------+ | | | | +-------+ |
| | | +-----+ | | +-----+ | | | | | | +-----+ | | +-----+ | | |
skipping to change at page 150, line 32 skipping to change at line 6879
Let's first suppose that the following ES was created (Figure 30). Let's first suppose that the following ES was created (Figure 30).
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
{ {
"ietf-ethernet-segment:ethernet-segments": { "ietf-ethernet-segment:ethernet-segments": {
"ethernet-segment": [ "ethernet-segment": [
{ {
"name": "esi1", "name": "esi1",
"ethernet-segment-identifier": "00:11:11:11:11:11:11:\ "ethernet-segment-identifier": "00:11:11:11:11:11:11:\
11:11:11", 11:11:11",
"esi-redundancy-mode": "all-active" "esi-redundancy-mode": "all-active"
}, },
{ {
"name": "esi2", "name": "esi2",
"ethernet-segment-identifier": "00:22:22:22:22:22:22:\ "ethernet-segment-identifier": "00:22:22:22:22:22:22:\
22:22:22", 22:22:22",
"esi-redundancy-mode": "all-active" "esi-redundancy-mode": "all-active"
} }
] ]
} }
} }
Figure 30: Example of L2NM Message Body to Configure an Ethernet Figure 30: An Example of an L2NM Message Body to Configure an
Segment Ethernet Segment
Figure 29 shows a simplified configuration to illustrate the use of Figure 31 shows a simplified configuration to illustrate the use of
the L2NM to configured VPWS-EVPN instance. the L2NM to configure a VPWS-EVPN instance.
{ {
"ietf-l2vpn-ntw:l2vpn-ntw": { "ietf-l2vpn-ntw:l2vpn-ntw": {
"vpn-services": { "vpn-services": {
"vpn-service": [ "vpn-service": [
{ {
"vpn-id": "vpws15432855", "vpn-id": "vpws15432855",
"vpn-description": "Sample VPWS-EVPN", "vpn-description": "Sample VPWS-EVPN",
"customer-name": "customer_15432855", "customer-name": "customer_15432855",
"vpn-type": "ietf-vpn-common:vpws-evpn", "vpn-type": "ietf-vpn-common:vpws-evpn",
skipping to change at page 155, line 30 skipping to change at line 7115
} }
} }
] ]
} }
} }
] ]
} }
} }
} }
Figure 31: Example of L2NM Message Body to Configure a VPWS-EVPN Figure 31: An Example of an L2NM Message Body to Configure a
Instance VPWS-EVPN Instance
A.5. Automatic ESI Assignment A.5. Automatic ESI Assignment
This section provides an example to illustrate how the L2NM can be This section provides an example to illustrate how the L2NM can be
used to manage ESI auto-assignment. We consider the sample EVPN used to manage ESI auto-assignment. We consider the sample EVPN
service delivered using the architecture depicted in Figure 32. service delivered using the architecture depicted in Figure 32.
ES ES
| +-----+ +--------------+ +-----+ | +-----+ +--------------+ +-----+
+----+ | | PE1 |======| |===| PE3 | +----+ +----+ | | PE1 |======| |===| PE3 | +----+
| +-------+ | | | | +-------+ CE3| | +-------+ | | | | +-------+ CE3|
| | | +-----+ | | +-----+ +----+ | | | +-----+ | | +-----+ +----+
| CE1| | | Core | | CE1| | | Core |
| | | +-----+ | | +-----+ +----+ | | | +-----+ | | +-----+ +----+
| +-------+ | | | | +-------+ CE2| | +-------+ | | | | +-------+ CE2|
+----+ | | PE2 |======| |===| PE4 | +----+ +----+ | | PE2 |======| |===| PE4 | +----+
| +-----+ +--------------+ +-----+ | +-----+ +--------------+ +-----+
LACP LACP
Figure 32: An Example of Automatic ESI Assignment Figure 32: An Example of Automatic ESI Assignment
Figure 33 and Figure 34 show how the L2NM is used to instruct both Figures 33 and 34 show how the L2NM is used to instruct both PE1 and
PE1 and PE2 to auto-assign the ESI to identify the ES used with CE1. PE2 to auto-assign the ESI to identify the ES used with CE1. In this
In this example, we suppose that LACP is enabled and that a Type 1 example, we suppose that LACP is enabled and that a Type 1 (T=0x01)
(T=0x01) is used as per Section 5 of [RFC7432]. Note that this is used as per Section 5 of [RFC7432]. Note that this example does
example does not include all the details to configure the EVPN not include all the details to configure the EVPN service but focuses
service, but focuses only on the ESI management part. only on the ESI management part.
{ {
"ietf-ethernet-segment:ethernet-segments": { "ietf-ethernet-segment:ethernet-segments": {
"ethernet-segment": [ "ethernet-segment": [
{ {
"name": "esi1", "name": "esi1",
"esi-type": "esi-type-1-lacp", "esi-type": "esi-type-1-lacp",
"esi-redundancy-mode": "all-active" "esi-redundancy-mode": "all-active"
} }
] ]
} }
} }
Figure 33: Example of L2NM Message Body to Auto-Assign Ethernet Figure 33: An Example of an L2NM Message Body to Auto-Assign
Segment Identifiers Ethernet Segment Identifiers
{ {
"ietf-l2vpn-ntw:l2vpn-ntw": { "ietf-l2vpn-ntw:l2vpn-ntw": {
"ietf-l2vpn-ntw:vpn-services": { "ietf-l2vpn-ntw:vpn-services": {
"vpn-service": [ "vpn-service": [
{ {
"vpn-id": "auto-esi-lacp", "vpn-id": "auto-esi-lacp",
"vpn-description": "Sample to illustrate auto-ESI", "vpn-description": "Sample to illustrate auto-ESI",
"vpn-type": "ietf-vpn-common:vpws-evpn", "vpn-type": "ietf-vpn-common:vpws-evpn",
"vpn-nodes": { "vpn-nodes": {
skipping to change at page 158, line 4 skipping to change at line 7232
"lacp-state": true, "lacp-state": true,
"system-id": "11:00:11:00:11:11", "system-id": "11:00:11:00:11:11",
"admin-key": 154 "admin-key": 154
} }
} }
}, },
"group": [ "group": [
{ {
"group-id": "gr1", "group-id": "gr1",
"ethernet-segment-identifier": "esi1" "ethernet-segment-identifier": "esi1"
} }
] ]
} }
] ]
} }
} }
] ]
} }
} }
] ]
} }
} }
} }
Figure 34: An Example of L2NM Message Body for ESI Auto-Assignment Figure 34: An Example of an L2NM Message Body for ESI Auto-Assignment
The auto-assigned ESI can be retrieved using, e.g., a GET RESTCONF 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 method. The assigned value will then be returned as shown in the
'esi-auto' data node in Figure 35. 'esi-auto' data node in Figure 35.
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
{ {
"ietf-ethernet-segment:ethernet-segments": { "ietf-ethernet-segment:ethernet-segments": {
"ethernet-segment": [ "ethernet-segment": [
{ {
"name": "esi1", "name": "esi1",
"ethernet-segment-identifier": "esi-type-1-lacp", "ethernet-segment-identifier": "esi-type-1-lacp",
"esi-auto": { "esi-auto": {
"auto-ethernet-segment-identifier": "01:11:00:11:00:11:\ "auto-ethernet-segment-identifier": "01:11:00:11:00:11:\
11:9a:00:00" 11:9a:00:00"
}, },
"esi-redundancy-mode": "all-active" "esi-redundancy-mode": "all-active"
} }
] ]
} }
} }
Figure 35: An Example of L2NM Message Body to Retrieve the Figure 35: An Example of an L2NM Message Body to Retrieve the
Assigned ESI Assigned ESI
A.6. VPN Network Access Precedence A.6. VPN Network Access Precedence
In reference to the example depicted in Figure 36, an L2VPN service In reference to the example depicted in Figure 36, an L2VPN service
involves two VPN network accesses to sites that belong to the same involves two VPN network accesses to sites that belong to the same
customer. customer.
+--------------+ +--------------+
|VPN-NODE | |VPN-NODE |
skipping to change at page 159, line 19 skipping to change at line 7293
| | +------------------ | | +------------------
| +--+-------+ | +--+-------+
| | | |
| +--+-------+ | +--+-------+
| | NET-ACC-2| Secondary | | NET-ACC-2| Secondary
| | +------------------ | | +------------------
| +--+-------+ | +--+-------+
| | | |
+--------------+ +--------------+
Figure 36: Example of Multiple VPN Network Accesses Figure 36: An Example of Multiple VPN Network Accesses
In order to tag one of these VPN network accesses as "primary" and 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 the other one as "secondary", Figure 37 shows an excerpt of the
corresponding L2NM configuration. In such a configuration, both corresponding L2NM configuration. In such a configuration, both
accesses are bound to the same "group-id" and the "precedence" data 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 node is set as a function of the intended role of each access
secondary). (primary or secondary).
{ {
"ietf-l2vpn-ntw:l2vpn-ntw": { "ietf-l2vpn-ntw:l2vpn-ntw": {
"vpn-services": { "vpn-services": {
"vpn-service": [ "vpn-service": [
{ {
"vpn-id": "Sample-Service", "vpn-id": "Sample-Service",
"vpn-nodes": { "vpn-nodes": {
"vpn-node": [ "vpn-node": [
{ {
skipping to change at page 161, line 4 skipping to change at line 7348
] ]
} }
} }
] ]
} }
} }
] ]
} }
} }
} }
Figure 37: Example of Message Body to Associate Priority Levels
with VPN Network Accesses Figure 37: An Example of a Message Body to Associate Priority
Levels with VPN Network Accesses
Acknowledgements Acknowledgements
During the discussions of this work, helpful comments, suggestions, During the discussions of this work, helpful comments, suggestions,
and reviews were received from: Sergio Belotti, Italo Busi, Miguel and reviews were received from: Sergio Belotti, Italo Busi, Miguel
Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque Gagliano, Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque Gagliano,
Christian Jacquenet, Kireeti Kompella, Julian Lucek, Moti Christian Jacquenet, Kireeti Kompella, Julian Lucek, Moti
Morgenstern, Erez Segev, and Tom Petch. Many thanks to them. Morgenstern, Tom Petch, and Erez Segev. Many thanks to them.
Luay Jalil, Jichun Ma, Daniel King, and Zhang Guiyu contributed to an Zhang Guiyu, Luay Jalil, Daniel King, and Jichun Ma contributed to an
early version of this document. early draft version of this document.
Thanks to Yingzhen Qu and Himanshu Shah for the rtgdir reviews, Thanks to Yingzhen Qu and Himanshu Shah for the rtgdir reviews,
Ladislav Lhotka for the yangdoctors review, Chris Lonvick for the Ladislav Lhotka for the yangdoctors review, Chris Lonvick for the
secdir review, and Dale Worley for the gen-art review. Special secdir review, and Dale Worley for the gen-art review. Special
thanks to Adrian Farrel for the careful Shepherd review. thanks to Adrian Farrel for the careful Shepherd review.
Thanks to Robert Wilton for the careful AD review and various Thanks to Robert Wilton for the careful AD review and various
suggestions to enhance the model. suggestions to enhance the model.
Thanks to Lars Eggert, Erik Kline, Roman Danyliw, Francesca Thanks to Roman Danyliw, Lars Eggert, Erik Kline, Francesca
Palombini, Zaheduzzaman Sarker, and Eric Vyncke for the IESG review. Palombini, Zaheduzzaman Sarker, and Éric Vyncke for the IESG review.
A YANG module for Ethernet segments was first defined in the context A YANG module for Ethernet segments was first defined in the context
of the EVPN device module [I-D.ietf-bess-evpn-yang]. of the EVPN device module [EVPN-YANG].
This work is partially supported by the European Commission under This work is partially supported by the European Commission under
Horizon 2020 grant agreement number 101015857 Secured autonomic Horizon 2020 Secured autonomic traffic management for a Tera of SDN
traffic management for a Tera of SDN flows (Teraflow). flows (Teraflow) project (grant agreement number 101015857).
Contributors Contributors
Victor Lopez Victor Lopez
Nokia Nokia
Email: victor.lopez@nokia.com Email: victor.lopez@nokia.com
Qin Wu Qin Wu
Huawei Huawei
Email: bill.wu@huawei.com Email: bill.wu@huawei.com
 End of changes. 367 change blocks. 
1523 lines changed or deleted 1528 lines changed or added

This html diff was produced by rfcdiff 1.48.