Skip to main content

A Layer 2 VPN Network YANG Model
draft-ietf-opsawg-l2nm-04

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 9291.
Authors Samier Barguil , Oscar Gonzalez de Dios , Mohamed Boucadair , Luis Angel Munoz
Last updated 2021-07-28
Replaces draft-barguil-opsawg-l2sm-l2nm
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 9291 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-opsawg-l2nm-04
OPSAWG                                                        S. Barguil
Internet-Draft                                  O. Gonzalez de Dios, Ed.
Intended status: Standards Track                              Telefonica
Expires: January 29, 2022                              M. Boucadair, Ed.
                                                                  Orange
                                                                L. Munoz
                                                                Vodafone
                                                           July 28, 2021

                    A Layer 2 VPN Network YANG Model
                       draft-ietf-opsawg-l2nm-04

Abstract

   This document defines a L2VPN Network YANG Model (L2NM) that can be
   used to manage the provisioning of Layer 2 Virtual Private Network
   (VPN) services within a network (e.g., service provider network).
   The L2NM complements the Layer 2 Service Model (L2SM) by providing a
   network-centric view of the service that is internal to a service
   providers.  As such, the L2NM is meant to be used by a network
   controller to derive the configuration information that will be sent
   to relevant network devices.

   Also, the document defines the initial versions of two IANA-
   maintained modules that defines a set of identities of BGP Layer 2
   encapsulation types and pseudowire types.

Editorial Note (To be removed by RFC Editor)

   Please update these statements within the document with the RFC
   number to be assigned to this document:

   o  "This version of this YANG module is part of RFC XXXX;"

   o  "RFC XXXX: Layer 2 VPN Network Model";

   o  reference: RFC XXXX

   Please update "RFC CCCC" to the RFC number to be assigned to I-
   D.ietf-opsawg-vpn-common.

   Also, please update the "revision" date of the YANG modules.

Barguil, et al.         Expires January 29, 2022                [Page 1]
Internet-Draft                    L2NM                         July 2021

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 29, 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Reference Architecture  . . . . . . . . . . . . . . . . . . .   6
   5.  Relation with other YANG Models . . . . . . . . . . . . . . .   9
   6.  Description of the L2NM YANG Module . . . . . . . . . . . . .  11
     6.1.  Overall Structure of the Module . . . . . . . . . . . . .  11
     6.2.  VPN Profiles  . . . . . . . . . . . . . . . . . . . . . .  12
     6.3.  Ethernet Segments . . . . . . . . . . . . . . . . . . . .  13
     6.4.  VPN Services  . . . . . . . . . . . . . . . . . . . . . .  15
     6.5.  Global Parameters Profiles  . . . . . . . . . . . . . . .  19
     6.6.  VPN Node  . . . . . . . . . . . . . . . . . . . . . . . .  23
       6.6.1.  BGP Auto-Discovery  . . . . . . . . . . . . . . . . .  26
       6.6.2.  Signaling Options . . . . . . . . . . . . . . . . . .  27

Barguil, et al.         Expires January 29, 2022                [Page 2]
Internet-Draft                    L2NM                         July 2021

     6.7.  VPN Network Access  . . . . . . . . . . . . . . . . . . .  32
       6.7.1.  Connection  . . . . . . . . . . . . . . . . . . . . .  34
       6.7.2.  EVPN-VPWS Service Instance  . . . . . . . . . . . . .  36
       6.7.3.  Ethernet OAM  . . . . . . . . . . . . . . . . . . . .  37
       6.7.4.  Services  . . . . . . . . . . . . . . . . . . . . . .  39
   7.  YANG Modules  . . . . . . . . . . . . . . . . . . . . . . . .  44
     7.1.  IANA BGP Layer 2 Encapsulation Types  . . . . . . . . . .  44
     7.2.  IANA Encapsulation Types  . . . . . . . . . . . . . . . .  49
     7.3.  L2NM  . . . . . . . . . . . . . . . . . . . . . . . . . .  56
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . 111
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 112
     9.1.  YANG Modules  . . . . . . . . . . . . . . . . . . . . . . 112
     9.2.  BGP Layer 2 Encapsulation Types . . . . . . . . . . . . . 113
     9.3.  Pseudowire Types  . . . . . . . . . . . . . . . . . . . . 114
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . 114
     10.1.  Normative References . . . . . . . . . . . . . . . . . . 114
     10.2.  Informative References . . . . . . . . . . . . . . . . . 117
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . . 122
     A.1.  BGP-based VPLS  . . . . . . . . . . . . . . . . . . . . . 122
     A.2.  BGP-based VPWS with LDP Signaling . . . . . . . . . . . . 127
     A.3.  LDP-based VPLS  . . . . . . . . . . . . . . . . . . . . . 130
     A.4.  VPWS-EVPN Service Instance  . . . . . . . . . . . . . . . 134
     A.5.  Automatic ESI Assignment  . . . . . . . . . . . . . . . . 139
     A.6.  VPN Network Access Precedence . . . . . . . . . . . . . . 143
   Appendix B.  Initial BGP Layer 2 Encapsulation Types  . . . . . . 144
   Appendix C.  Initial PW Types . . . . . . . . . . . . . . . . . . 145
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . . 147
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . . 147
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 147

1.  Introduction

   [RFC8466] defines an L2VPN Service Model (L2SM) YANG data model that
   can be used for Layer 2 Virtual Private Network (L2VPN) service
   ordering matters between customers and service providers.  This
   document complements the L2SM by creating a network-centric view of
   the service: the L2VPN Network Model (L2NM).

   The L2NM module (Section 7.3) can be exposed, for example, by a
   network controller to a service controller within the service
   providers network.  In particular, the model can be used in the
   communication between the entity that interacts directly with the
   customer, the service orchestrator (either fully automated or a human
   operator), and the entity in charge of network orchestration and
   control (a.k.a., network controller/orchestrator) by allowing for
   more network-centric information to be included.

Barguil, et al.         Expires January 29, 2022                [Page 3]
Internet-Draft                    L2NM                         July 2021

   The L2NM supports capabilities, such as exposing operational
   parameters, transport protocols selection, and precedence.  It can
   also serve as a multi-domain orchestration interface.

   This document uses the common Virtual Private Network (VPN) YANG
   module defined in [I-D.ietf-opsawg-vpn-common].  Also, the document
   defines the initial versions of two IANA-maintained modules that
   define a set of identities of BGP Layer 2 encapsulation types
   (Section 7.1) and pseudowire types (Section 7.2).  Relying upon these
   IANA-maintained modules is meant to provide more flexibility in
   handling new types rather than be limited by a set of identities
   defined in the L2NM itself.

   The YANG data models in this document conforms to the Network
   Management Datastore Architecture (NMDA) defined in [RFC8342].

   The L2NM module(Section 7.3) is scoped for a variety of Layer 2
   Virtual Private Networks, for example VPLS (see [RFC4761] or
   [RFC4762]), VPWS (see in Section 3.1.1 of [RFC4664]) and various
   flavors of EVPN (see VPWS EVPN [RFC8214], PBB EVPN [RFC7623], EVPN
   over MPLS[RFC7432] and EVPN over VxLAN [RFC8365].  The module is
   prepared to easily support future Layer 2 VPN flavors and procedures.

   A set of examples to illustrate the use of the L2MN module is
   provided in Appendix A.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   This document assumes that the reader is familiar with the contents
   of [RFC6241], [RFC7950], [RFC8466], [RFC8309], and uses terminology
   from those documents.

   This document uses the term "network model" defined in Section 2.1 of
   [RFC8969].

   The meaning of the symbols in YANG tree diagrams is [RFC8340].

   This document uses the term "network model" defined in Section 2.1 of
   [RFC8969].

   This document makes use of the following terms:

Barguil, et al.         Expires January 29, 2022                [Page 4]
Internet-Draft                    L2NM                         July 2021

   Ethernet Segment (ES)  Refers to the set of the Ethernet links that
      are used by a customer site (device or network) to connect to one
      or more Provider Edges (PEs).

   Layer 2 VPN Customer Service Model (L2SM):  Describes the service
      characterization of an L2VPN that interconnects a set of sites
      from the customer's perspective.  The customer service model does
      not provide details on the service provider network.  The L2VPN
      customer service model is defined in [RFC8466].

   Layer 2 VPN Service Network Model (L2NM):  Refers to the YANG module
      that describes an L2VPN service with a network-centric view.  It
      contains information of the service providers network and might
      include allocated resources.  Network controllers can use it to
      manage the Layer 2 VPN service configuration in the service
      providers network.  The YANG module can be consumed by a service
      orchestrator to request a VPN service to a network controller or
      to expose the list of active L2VPN services.

   Service orchestrator:  Refers to a functional entity that interacts
      with the customer of an L2VPN relying upon, e.g., L2SM.  The
      service orchestrator is responsible of the CE-PE attachment
      circuits, the PE selection, and requesting the activation of the
      L2VPN service to a network controller.

   Network controller:  Denotes a functional entity responsible for the
      management of the service providers network.

   VPN node:  Is an abstraction that represents a set of policies
      applied on a PE and that belong to a single VPN service.  A VPN
      service involves one or more VPN nodes.  The VPN node will
      identify the service providers node on which the VPN is deployed.

   VPN network access:  Is an abstraction that represents the network
      interfaces that are associated to a given VPN node.  Traffic
      coming from the VPN network access belongs to the VPN.  The
      attachment circuits (bearers) between Customer Edges (CEs) and PEs
      are terminated in the VPN network access.

   VPN service provider:  Is a service providers that offers L2VPN-
      related services.

   Service Provider Network (SP Network):  Is a network able to provide
      L2VPN-related services.

Barguil, et al.         Expires January 29, 2022                [Page 5]
Internet-Draft                    L2NM                         July 2021

3.  Acronyms

   The following acronyms are used in the document:

   ACL     Access Control List
   BGP     Border Gateway Protocol
   CE      Customer Edge
   ES      Ethernet Segment
   ESI     Ethernet Segment Identifier
   EVPN    Ethernet VPN
   L2VPN   Layer 2 Virtual Private Network
   L2SM    L2VPN Service Model
   L2NM    L2VPN Network Model
   MAC     Media Access Control
   PBB     Provider Backbone Bridging
   PE      Provider Edge
   QoS     Quality of Service
   RD      Route Distinguisher
   RT      Route Target
   VPLS    Virtual Private LAN Service
   VPN     Virtual Private Network
   VPWS    Virtual Private Wire Service
   VRF     Virtual Routing and Forwarding

4.  Reference Architecture

   Figure 1 illustrates how the L2NM is used.  As a reminder, this
   figure is an expansion of the architecture presented in Section 3 of
   [RFC8466] and decomposes the box marked "orchestration" in that
   figure into three separate functional components called "Service
   Orchestration", "Network Orchestration", and "Domain Orchestration".

   The reader may refer to [RFC8309] for the distinction between the
   "Customer Service Model", the "Service Delivery Model", the "Network
   Configuration Model", and the "Device Configuration Model".  The
   "Domain Orchestration" and "Config Manager" roles may be performed by
   "SDN Controllers".

Barguil, et al.         Expires January 29, 2022                [Page 6]
Internet-Draft                    L2NM                         July 2021

                             +---------------+
                             |   Customer    |
                             +-------+-------+
             Customer Service Model  |
                 e.g., l2vpn-svc     |
                             +-------+-------+
                             |    Service    |
                             | Orchestration |
                             +-------+-------+
              Network Model          |
                l2vpn-ntw            |
                             +-------+-------+
                             |   Network     |
                             | Orchestration |
                             +-------+-------+
       Network Configuration Model   |
                          ___________|___________
                         |                       |
                +--------+------+       +--------+------+
                |    Domain     |       |     Domain    |
                | Orchestration |       | Orchestration |
                +---+-----------+       +--------+------+
     Device         |        |                   |
     Configuration  |        |                   |
     Model          |        |                   |
               +----+----+   |                   |
               | Config  |   |                   |
               | Manager |   |                   |
               +----+----+   |                   |
                    |        |                   |
                    | NETCONF/CLI..................
                    |        |                   |
             +------------------------------------------------+
                                 Network

                            +++++++
                            + AAA +
                            +++++++

    ++++++++   Bearer    ++++++++           ++++++++      ++++++++
    + CE A + ----------- + PE A +           + PE B + ---- + CE B +
    ++++++++  Connection ++++++++           ++++++++      ++++++++

               Site A                               Site B

                    Figure 1: L2SM and L2NM Interaction

Barguil, et al.         Expires January 29, 2022                [Page 7]
Internet-Draft                    L2NM                         July 2021

   The customer may use various means to request a service that may
   trigger the instantiation of a L2NM.  The customer may use the L2SM
   or may rely upon more abstract models to request a service that
   relies upon an L2VPN service.  For example, the customer may supply
   an IP Connectivity Provisioning Profile (CPP) [RFC7297], an enhanced
   VPN (VPN+) service [I-D.ietf-teas-enhanced-vpn], or an IETF network
   slice [I-D.ietf-teas-ietf-network-slices].

   Note also that both the L2SM and the L2NM may be used in the context
   of the Abstraction and Control of TE Networks (ACTN) architecture
   [RFC8453].  Figure 2 shows the Customer Network Controller (CNC), the
   Multi-Domain Service Coordinator (MDSC), and the Provisioning Network
   Controller (PNC).

Barguil, et al.         Expires January 29, 2022                [Page 8]
Internet-Draft                    L2NM                         July 2021

                  +----------------------------------+
                  | Customer                         |
                  | +-----------------------------+  |
                  | |             CNC             |  |
                  | +-----------------------------+  |
                  +----+-----------------------+-----+
                       |                       |
                       | L2SM                  | L2SM
                       |                       |
             +---------+---------+   +---------+---------+
             | MDSC              |   |       MDSC        |
             | +---------------+ |   |     (parent)      |
             | |    Service    | |   +---------+---------+
             | | Orchestration | |             |
             | +-------+-------+ |             | L2NM
             |         |         |             |
             |         | L2NM    |   +---------+---------+
             |         |         |   |       MDSC        |
             | +-------+-------+ |   |      (child)      |
             | |    Network    | |   +---------+---------+
             | | Orchestration | |             |
             | +---------------+ |             |
             +---------+---------+             |
                       |                       |
                       | Network Configuration |
                       |                       |
          +------------+-------+     +---------+------------+
          | Domain             |     |           Domain     |
          | Controller         |     |           Controller |
          |       +---------+  |     |    +---------+       |
          |       |   PNC   |  |     |    |   PNC   |       |
          |       +---------+  |     |    +---------+       |
          +------------+-------+     +---------+------------+
                       |                       |
                       | Device Configuration  |
                       |                       |
                  +----+---+              +----+---+
                  | Device |              | Device |
                  +--------+              +--------+

              Figure 2: L2SM and L2NM in the Context of ACTN

5.  Relation with other YANG Models

   The "ietf-vpn-common" module [I-D.ietf-opsawg-vpn-common] includes a
   set of identities, types, and groupings that are meant to be reused
   by VPN-related YANG modules independently of the layer (e.g., Layer
   2, Layer 3) and the type of the module (e.g., network model, service

Barguil, et al.         Expires January 29, 2022                [Page 9]
Internet-Draft                    L2NM                         July 2021

   model) including future revisions of existing models (e.g.,
   [RFC8466]).  The L2NM reuses these common types and groupings.

   Also, the L2NM uses the IANA-maintained modules "iana-bgp-l2-encaps"
   (Section 7.1) and "iana-pseudowire-types" (Section 7.2) to identify a
   layer 2 encapsulation type.

   As discussed in Section 4, the L2NM is meant to manage L2VPN services
   within a service provider network.  The module provides a network
   view of the service.  Such a view is only visible within the service
   provider and is not exposed outside (to customers, for example).  The
   following discusses how L2NM interfaces with other YANG modules:

   L2SM:  L2NM is not a customer service model.

      The internal view of the service (i.e., L2NM) may be mapped to an
      external view which is visible to customers: L2VPN Service YANG
      data Model (L2SM) [RFC8466].

      The L2NM can be fed with inputs that are requested by customers,
      typically, relying upon an L2SM template.  Concretely, some parts
      of the L2SM module can be directly mapped into L2NM while other
      parts are generated as a function of the requested service and
      local guidelines.  Finally, there are parts local to the service
      provider and do not map directly to L2SM.

      Note that the use of L2NM within a service provider does not
      assume nor preclude exposing the VPN service via the L2SM.  This
      is deployment-specific.  Nevertheless, the design of L2NM tries to
      align as much as possible with the features supported by the L2SM
      to ease grafting both L2NM and L2SM for the sake of highly
      automated VPN service provisioning and delivery.

   Network Topology Modules:  An L2VPN involves nodes that are part of a
      topology managed by the service provider network.  Such topology
      can be represented using the network topology module in [RFC8345].

   Device Modules:  L2NM is not a device model.

      Once a global VPN service is captured by means of the L2NM, the
      actual activation and provisioning of the VPN service will involve
      a variety of device modules to tweak the required functions for
      the delivery of the service.  These functions are supported by the
      VPN nodes and can be managed using device YANG modules.  A non-
      comprehensive list of such device YANG modules is provided below:

      *  Interfaces [RFC8343].

Barguil, et al.         Expires January 29, 2022               [Page 10]
Internet-Draft                    L2NM                         July 2021

      *  BGP [I-D.ietf-idr-bgp-model].

      *  MPLS [RFC8960].

      *  ACLs [RFC8519].

      How the L2NM is used to derive device-specific actions is
      implementation-specific.

6.  Description of the L2NM YANG Module

   The L2NM ('ietf-l2vpn-ntw', Section 7.3) is meant to manage L2VPNs
   within a service provider network.  In particular, the 'ietf-l2vpn-
   ntw' module can be used to create, modify, delete and retrieve L2VPN
   services in a network controller.  The module is designed to minimize
   the amount of customer-related information.

   The full tree diagram of the module can be generated using the
   "pyang" tool [PYANG].  That tree is not included here because it is
   too long (Section 3.3 of [RFC8340]).  Instead, subtrees are provided
   for the reader's convenience.

6.1.  Overall Structure of the Module

   The 'ietf-l2vpn-ntw' module uses two main containers: 'vpn-profiles',
   'ethernet-segments', and 'vpn-services' (see Figure 3).

   The 'vpn-profiles' container is used by the provider to maintain a
   set of common VPN profiles that apply to one or several VPN services
   (Section 6.2).

   The 'ethernet-segments' container provides a set of data related to
   Ethernet Segments (ESs).  This container is present only for EVPN-
   related L2VPN types.  More details are provided in Section 6.3.

   The 'vpn-services' container maintains the set of L2VPN services
   managed in the service providers network.  The module allows to
   create a new L2VPN service by adding a new instance of 'vpn-service'.
   The 'vpn-service' is the data structure that abstracts the VPN
   service (Section 6.4).

Barguil, et al.         Expires January 29, 2022               [Page 11]
Internet-Draft                    L2NM                         July 2021

            module: ietf-l2vpn-ntw
              +--rw l2vpn-ntw
                 +--rw vpn-profiles
                 |  ...
                 +--rw ethernet-segments
                 |  ...
                 +--rw vpn-services
                    +--rw vpn-service* [vpn-id]
                       ...
                       +--rw vpn-nodes
                          +--rw vpn-node* [vpn-node-id]
                             ...
                             +--rw vpn-network-accesses
                                +--rw vpn-network-access* [id]
                                   ...

                   Figure 3: Overall L2NM Tree Structure

6.2.  VPN Profiles

   The 'vpn-profiles' container (Figure 4) allows the VPN service
   provider to define and maintain a set of VPN profiles
   [I-D.ietf-opsawg-vpn-common] that apply to one or several VPN
   services.

   This document does not make any assumption about the exact definition
   of these profiles.  The exact definition of the profiles is local to
   each VPN service provider.  The model only includes an identifier to
   these profiles in order to ease identifying and binding local
   policies when building a VPN service.  As shown in Figure 4, the
   following identifiers can be included:

   'external-connectivity-identifier':  This identifier refers to a
      profile that defines the external connectivity provided to a VPN
      service (or a subset of VPN sites).  An external connectivity may
      be an access to the Internet or a restricted connectivity such as
      access to a public/private cloud.

   'encryption-profile-identifier':  An encryption profile refers to a
      set of policies related to the encryption schemes and setup that
      can be applied when building and offering a VPN service.

   'qos-profile-identifier':  A Quality of Service (QoS) profile refers
      to as set of policies such as classification, marking, and actions
      (e.g., [RFC3644]).

Barguil, et al.         Expires January 29, 2022               [Page 12]
Internet-Draft                    L2NM                         July 2021

   'bfd-profile-identifier':  A Bidirectional Forwarding Detection (BFD)
      profile refers to a set of BFD [RFC5880] policies that can be
      invoked when building a VPN service.

   'forwarding-profile-identifier':  A forwarding profile refers to the
      policies that apply to the forwarding of packets conveyed within a
      VPN.  Such policies may consist, for example, at applying Access
      Control Lists (ACLs).

   'routing-profile-identifier':  A routing profile refers to a set of
      routing policies that will be invoked (e.g., BGP policies) when
      delivering the VPN service.

            +--rw l2vpn-ntw
               +--rw vpn-profiles
               |  +--rw valid-provider-identifiers
               |     +--rw external-connectivity-identifier* [id]
               |     |       {external-connectivity}?
               |     |  +--rw id    string
               |     +--rw encryption-profile-identifier* [id]
               |     |  +--rw id    string
               |     +--rw qos-profile-identifier* [id]
               |     |  +--rw id    string
               |     +--rw bfd-profile-identifier* [id]
               |     |  +--rw id    string
               |     +--rw forwarding-profile-identifier* [id]
               |     |  +--rw id    string
               |     +--rw routing-profile-identifier* [id]
               |        +--rw id    string
               +--rw ethernet-segments
               |  ...
               +--rw vpn-services
                  ...

                 Figure 4: VPN Profiles Subtree Structure

6.3.  Ethernet Segments

   The 'ethernet-segments' container is used to list a set of ESes that
   are defined in an EVPN service.  In reference to the structure shown
   in Figure 5, the following data nodes can be included:

   'name':  Sets a name to uniquely identify an ES.  This name is called
      in the VPN network access level to handle multi-homing, for
      example.

   'esi-type':  Indicates the ESI type as discussed in Section 5 of
      [RFC7432].  ESI can be automatically assigned either with or

Barguil, et al.         Expires January 29, 2022               [Page 13]
Internet-Draft                    L2NM                         July 2021

      without indicating a pool from which the ESI should be taken.  The
      following types are supported:

      'esi-type-0':  The ESI is directly configured by the VPN service
         provider.

      'esi-type-1':  The ESI is auto-generated from the IEEE 802.1AX
         Link Aggregation Control Protocol (LACP) [IEEE802.1AX].

      'esi-type-2':  The ESI is auto-generated and determined based on
         the Layer 2 bridge protocol.

      'esi-type-3':  The ESI is a MAC-based ESI value that can be auto-
         generated or configured by the VPN service provider.

      'esi-type-4':  The ESI is auto-generated or configured by the VPN
         service provider based on the Router-ID.  The 'router-id'
         supplied in Section 6.6 can be used to auto-derive an ESI when
         this type is used.

      'esi-type-5':  The ESI is auto-generated or configured by the VPN
         service provider based on the Autonomous System (AS) number.
         The 'local-autonomous-system' supplied in Section 6.5 can be
         used to auto-derive an ESI when this type is used.

   'esi-redundancy-mode':  Specifies the EVPN redundancy mode for a
      given ES.  The following modes are supported: Single-Active
      (Section 14.1.1 of [RFC7432]) or All-Active (Section 14.1.2 of
      [RFC7432]).

   'df-election':  Specifies a set of parameters related to the
      Designated Forwarder (DF) election (Section 8.5 of [RFC7432]).
      For example, this data node can be used to indicate an election
      method (e.g., [RFC8584] or [I-D.ietf-bess-evpn-pref-df]).  If no
      election method is indicated, the default one defined in
      Section 8.5 of [RFC7432] is used.

   'split-horizon-filtering':  Controls the activation of the split-
      horizon filtering for an ES (Section 8.3 of [RFC7432]).

   'backbone-src-mac':  Associates a Provider Backbone MAC (B-MAC)
      address with an ES.  This is particularly useful for All-Active
      multihomed ESes (Section 9.1 of [RFC7623]).

Barguil, et al.         Expires January 29, 2022               [Page 14]
Internet-Draft                    L2NM                         July 2021

     +--rw l2vpn-ntw
        +--rw vpn-profiles
        |  ...
        +--rw ethernet-segments
        |  +--rw ethernet-segment* [name]
        |     +--rw name                                 string
        |     +--rw esi-type?                            identityref
        |     +--rw (esi-choice)?
        |     |  +--:(directly-assigned)
        |     |  |  +--rw ethernet-segment-identifier?   yang:hex-string
        |     |  +--:(auto-assigned)
        |     |     +--rw esi-auto
        |     |        +--rw (auto-mode)?
        |     |        |  +--:(from-pool)
        |     |        |  |  +--rw esi-pool-name?                string
        |     |        |  +--:(full-auto)
        |     |        |     +--rw auto?                         empty
        |     |        +--ro auto-ethernet-segment-identifier?
        |     |                yang:hex-string
        |     +--rw esi-redundancy-mode?                 identityref
        |     +--rw df-election
        |     |  +--rw df-election-method?   identityref
        |     |  +--rw preference?           uint16
        |     |  +--rw revertive?            boolean
        |     |  +--rw election-wait-time?   uint32
        |     +--rw split-horizon-filtering?             boolean
        |     +--rw pbb
        |        +--rw backbone-src-mac?   yang:mac-address
        +--rw vpn-services
           ...

                    Figure 5: Ethernet Segments Subtree

6.4.  VPN Services

   The 'vpn-service' is the data structure that abstracts an L2VPN
   service in the service provider network.  Each 'vpn-service' is
   uniquely identified by an identifier: 'vpn-id'.  Such 'vpn-id' is
   only meaningful locally within the network controller.  The subtree
   of the 'vpn-services' is shown in Figure 6.

Barguil, et al.         Expires January 29, 2022               [Page 15]
Internet-Draft                    L2NM                         July 2021

          +--rw vpn-services
             +--rw vpn-service* [vpn-id]
                +--rw vpn-id                        vpn-common:vpn-id
                +--rw vpn-name?                     string
                +--rw vpn-description?              string
                +--rw customer-name?                string
                +--rw parent-service-id?            vpn-common:vpn-id
                +--rw vpn-type?                     identityref
                +--rw vpn-service-topology?         identityref
                +--rw bgp-ad-enabled?               boolean
                +--rw signaling-type?               identityref
                +--rw global-parameters-profiles
                |  ...
                +--rw underlay-transport
                |  +--rw (type)?
                |     +--:(abstract)
                |     |  +--rw transport-instance-id?   string
                |     |  +--rw instance-type?           identityref
                |     +--:(protocol)
                |        +--rw protocol*                identityref
                +--rw status
                |  +--rw admin-status
                |  |  +--rw status?         identityref
                |  |  +--rw last-change?   yang:date-and-time
                |  +--ro oper-status
                |     +--ro status?         identityref
                |     +--ro last-change?   yang:date-and-time
                +--rw vpn-nodes
                   ...

                      Figure 6: VPN Services Subtree

   The description of the VPN service data nodes that are depicted in
   Figure 6 are as follows:

   'vpn-id':  Is an identifier that is used to uniquely identify the
      L2VPN service within L2NM scope.

   'vpn-name':  Associates a name with the service in order to
      facilitate the identification of the service.

   'vpn-description':  Includes a textual description of the service.

      The internal structure of a VPN description is local to each VPN
      service provider.

   'customer-name':  Indicates the name of the customer who ordered the
      service.

Barguil, et al.         Expires January 29, 2022               [Page 16]
Internet-Draft                    L2NM                         July 2021

   'parent-service-id':  Refers to an identifier of the parent service
      (e.g., L2SM, IETF network slice, VPN+) that triggered the creation
      of the L2VPN service.  This identifier is used to easily correlate
      the (network) service as built in the network with a service
      order.  A controller can use that correlation to enrich or
      populate some fields (e.g., description fields) as a function of
      local deployments.

   'vpn-type':  Indicates the L2VPN type.  The following types, defined
      in [I-D.ietf-opsawg-vpn-common], can be used for the L2NM:

      'vpls':  Virtual Private LAN Service (VPLS) as defined in
         [RFC4761] or [RFC4762].

      'vpws':  Virtual Private Wire Service (VPWS) as defined in
         Section 3.1.1 of [RFC4664].

      'vpws-evpn':  VPWS as defined in [RFC8214].

      'pbb-evpn':  Provider Backbone Bridging (PBB) EVPNs as defined in
         [RFC7623].

      'mpls-evpn':  MPLS-based EVPNs [RFC7432].

      'vxlan-evpn':  VXLAN based EVPNs [RFC8365].

      The type is used as a condition for the presence of some data
      nodes in the L2NM.

   'vpn-service-topology':  Indicates the network topology for the
      service: hub-spoke, any-to-any, or custom.

   'bgp-ad-enabled':  Controls whether BGP auto-discovery is enabled.
      If so, additional data nodes are included (Section 6.6.1).

   'signaling-type':  Indicates the signaling that is used for setting
      pseudowires.  Signaling type values are taken from
      [I-D.ietf-opsawg-vpn-common].  The following signaling options are
      supported:

      'bgp-signaling':  The L2NM supports two flavors of BGP-signaled
         L2VPNs:

         'l2vpn-bgp':  The service is a Multipoint VPLS that uses a BGP
            control plane as described in [RFC4761] and [RFC6624].

Barguil, et al.         Expires January 29, 2022               [Page 17]
Internet-Draft                    L2NM                         July 2021

         'evpn-bgp':  The service is a Multipoint VPLS that uses also a
            BGP control plane, but also includes the additional features
            and related parameters [RFC7432] and [RFC7209].

      'ldp-signaling':  A Multipoint VPLS that uses a mesh of LDP-
         signaled Pseudowires [RFC6074].

      l2tp-signaling':  The L2NM uses L2TP-signaled Pseudowires as
         described in [RFC6074].

      Table 1 summarizes the allowed signaling types for each VPN
      service type ('vpn-type').  See Section 6.6.2 for more details.

   'global-parameters-profiles':  Defines reusable parameters for the
      same L2VPN service.

      More details are provided in Section 6.5.

   'underlay-transport':  Describes the preference for the transport
      technology to carry the traffic of the VPN service.  This
      preference is especially useful in networks with multiple domains
      and Network-to-Network Interface (NNI) types.  The underlay
      transport can be expressed as an abstract transport instance
      (e.g., an identifier of a VPN+ instance, a virtual network
      identifier, or a network slice name) or as an ordered list of the
      actual protocols to be enabled in the network.

      A rich set of protocol identifiers that can be used to refer to an
      underlay transport are defined in [I-D.ietf-opsawg-vpn-common].

   'status':  Is used to track the service status of a given VPN
      service.  Both operational and administrative status are
      maintained together with a timestamp.  For example, a service can
      be created, but not put into effect.

      Administrative and operational status can be used as a trigger to
      detect service anomalies.  For example, a service that is declared
      at the service layer as being active but still inactive at the
      network layer is an indication that network provision actions are
      needed to align the observed service status with the expected
      service status.

   'vpn-node':  Is an abstraction that represents a set of policies
      applied to a network node and that belong to a single 'vpn-
      service'.  An L2VPN service is typically built by adding instances
      of 'vpn-node' to the 'vpn-nodes' container.

Barguil, et al.         Expires January 29, 2022               [Page 18]
Internet-Draft                    L2NM                         July 2021

      A 'vpn-node' contains 'vpn-network-accesses', which are the
      interfaces attached to the VPN by which the customer traffic is
      received.  Therefore, the customer sites are connected to the
      'vpn-network-accesses'.

      Note that, as this is a network data model, the information about
      customers sites is not required in the model.  Such information is
      rather relevant in the L2SM.  Whether that information is included
      in the L2NM, e.g., to populate the various 'description' data node
      is implementation-specific.

      More details are provided in Section 6.6.

   +------------+------------------------------------------------------+
   | VPN Type   | Signaling Options                                    |
   +------------+------------------------------------------------------+
   | vpls       | l2tp-signaling, ldp-signaling, bgp-signaling (l2vpn- |
   |            | bgp)                                                 |
   | vpws       | l2tp-signaling, ldp-signaling, bgp-signaling (l2vpn- |
   |            | bgp)                                                 |
   | vpws-evpn  | bgp-signaling (evpn-bgp)                             |
   | pbb-evpn   | bgp-signaling (evpn-bgp)                             |
   | mpls-evpn  | bgp-signaling (evpn-bgp)                             |
   | vxlan-evpn | bgp-signaling (evpn-bgp)                             |
   +------------+------------------------------------------------------+

           Table 1: Valid Signaling Options per VPN Service Type

6.5.  Global Parameters Profiles

   The 'global-parameters-profile' defines reusable parameters for the
   same L2VPN service instance ('vpn-service').  Global parameters
   profile are defined at the VPN service level and then called at the
   VPN node and VPN network access levels.  Each VPN instance profile is
   identified by 'profile-id'.  Some of the data nodes can be adjusted
   at the VPN node or VPN network access levels.  These adjusted values
   take precedence over the global ones.  The subtree of 'global-
   parameters-profile' is depicted in Figure 7.

         ...
         +--rw vpn-services
            +--rw vpn-service* [vpn-id]
               ...
               +--rw global-parameters-profiles
               |  +--rw global-parameters-profile* [profile-id]
               |     +--rw profile-id                  string
               |     +--rw (rd-choice)?
               |     |  +--:(directly-assigned)

Barguil, et al.         Expires January 29, 2022               [Page 19]
Internet-Draft                    L2NM                         July 2021

               |     |  |  +--rw rd?
               |     |  |          rt-types:route-distinguisher
               |     |  +--:(directly-assigned-suffix)
               |     |  |  +--rw rd-suffix?            uint16
               |     |  +--:(auto-assigned)
               |     |  |  +--rw rd-auto
               |     |  |     +--rw (auto-mode)?
               |     |  |     |  +--:(from-pool)
               |     |  |     |  |  +--rw rd-pool-name?   string
               |     |  |     |  +--:(full-auto)
               |     |  |     |     +--rw auto?           empty
               |     |  |     +--ro auto-assigned-rd?
               |     |  |             rt-types:route-distinguisher
               |     |  +--:(auto-assigned-suffix)
               |     |  |  +--rw rd-auto-suffix
               |     |  |     +--rw (auto-mode)?
               |     |  |     |  +--:(from-pool)
               |     |  |     |  |  +--rw rd-pool-name?        string
               |     |  |     |  +--:(full-auto)
               |     |  |     |     +--rw auto?                empty
               |     |  |     +--ro auto-assigned-rd-suffix?   uint16
               |     |  +--:(no-rd)
               |     |     +--rw no-rd?                empty
               |     +--rw vpn-target* [id]
               |     |  +--rw id                   int8
               |     |  +--rw route-targets* [route-target]
               |     |  |  +--rw route-target    rt-types:route-target
               |     |  +--rw route-target-type
               |     |          rt-types:route-target-type
               |     +--rw vpn-policies
               |     |  +--rw import-policy?   string
               |     |  +--rw export-policy?   string
               |     +--rw local-autonomous-system?    inet:as-number
               |     +--rw svc-mtu?                    uint32
               |     +--rw ce-vlan-preservation?       boolean
               |     +--rw ce-vlan-cos-perservation?   boolean
               |     +--rw control-word-negotiation?   boolean
               |     +--rw mac-policies
               |     |  +--rw mac-addr-limit
               |     |  |  +--rw mac-num-limit?   uint16
               |     |  |  +--rw time-interval?   uint32
               |     |  |  +--rw action?          identityref
               |     |  +--rw mac-loop-prevention
               |     |     +--rw window?            uint32
               |     |     +--rw frequency?         uint32
               |     |     +--rw retry-timer?       uint32
               |     |     +--rw protection-type?   identityref
               |     +--rw multicast-like {vpn-common:multicast}?

Barguil, et al.         Expires January 29, 2022               [Page 20]
Internet-Draft                    L2NM                         July 2021

               |        +--rw enabled?                 boolean
               |        +--rw customer-tree-flavors
               |           +--rw tree-flavor*   identityref
                        ...

               Figure 7: Global Parameters Profiles Subtree

   The description of the global parameters profile is as follows:

   'profile-id':  Uniquely identifies a global parameter profile.

   'rd':  As defined in [I-D.ietf-opsawg-vpn-common], these RD
      assignment modes are supported: direct assignment, automatic
      assignment from a given pool, automatic assignment, and no
      assignment.  For illustration purposes, the following modes can be
      used in the deployment cases:

      'directly-assigned':  The VPN service provider (service
         orchestrator) assigns explicitly RDs.

      'full-auto':  The network controller auto-assigns RDs.

      'no-rd':  The VPN service provider (service orchestrator)
         explicitly wants no RD to be assigned.

      Also, the module accommodates deployments where only the Assigned
      Number subfield of RDs is assigned from a pool while the
      Administrator subfield is set to, e.g., the Router ID that is
      assigned to a VPN node.  The module supports these modes for
      managing the Assigned Number subfield: explicit assignment, auto-
      assignment from a pool, and full auto-assignment.

   'vpn-targets':  Specifies RT import/export rules for the VPN service.

   'local-autonomous-system':  Indicates the Autonomous System Number
      (ASN) that is configured for the VPN node.  The ASN can be used to
      auto-derive some other attributes such as RDs or Ethernet Segment
      Identifiers (ESIs).

   'svc-mtu':  Is the service MTU for an L2VPN service.  It is also
      known as the maximum transmission unit or maximum frame size.
      When a frame is larger than the MTU, it is fragmented to
      accommodate the MTU of the network.

   'ce-vlan-preservation':  Is set to preserve the CE-VLAN ID from
      ingress to egress, i.e., CE-VLAN tag of the egress frame are
      identical to those of the ingress frame that yielded this egress
      service frame.  If All-to-One bundling within a site is enabled,

Barguil, et al.         Expires January 29, 2022               [Page 21]
Internet-Draft                    L2NM                         July 2021

      then preservation applies to all ingress service frames.  If All-
      to-One bundling is disabled, then preservation applies to tagged
      Ingress service frames having CE-VLAN ID 1 through 4094.

   'ce-vlan-cos-perservation':  Controls the CE VLAN CoS preservation.
      When set, PCP bits in the CE-VLAN tag of the egress frame are
      identical to those of the ingress frame that yielded this egress
      service frame.

   'control-word-negotiation':  Controls whether control-word
      negotiation is enabled (if set to true) or not (if set to false).
      Refer to Section 7 of [RFC8077] for more details.

   'mac-policies':  Includes a set of MAC policies that apply to the
      service:

      'mac-addr-limit':  Is a container of MAC address limit
         configuration.  It includes the following data nodes:

         'mac-num-limit':  Maximum number of MAC addresses learned from
            the customer for a single service instance.

         'time-interval':  The aging time of the mac address.

         'action':  Specifies the action when the upper limit is
            exceeded: drop the packet, flood the packet, or simply send
            a warning log message.

      'mac-loop-prevention':  Container for MAC loop prevention.

         'window':  The timer when a MAC mobility event is detected.

         'frequency':  The number of times to detect MAC duplication,
            where a 'duplicate MAC address' situation has occurred and
            the duplicate MAC address has been added to a list of
            duplicate MAC addresses.

         'retry-timer':  The retry timer.  When the retry timer expires,
            the duplicate MAC address will be flushed from the MAC-VRF.

         'protection-type':  It defines the protection type

   multicast-like':  Controls whether multicast is allowed in the
      service.

Barguil, et al.         Expires January 29, 2022               [Page 22]
Internet-Draft                    L2NM                         July 2021

6.6.  VPN Node

   The 'vpn-node' is an abstraction that represents a set of policies/
   configurations applied to a network node and that belong to a single
   'vpn-service'.  A 'vpn-node' contains 'vpn-network-accesses', which
   are the interfaces involved in the creation of the VPN.  The customer
   sites are connected to the 'vpn-network-accesses'.

Barguil, et al.         Expires January 29, 2022               [Page 23]
Internet-Draft                    L2NM                         July 2021

      +--rw l2vpn-ntw
         +--rw vpn-profiles
         |  ...
         +--rw ethernet-segments
         |  ...
         +--rw vpn-services
            +--rw vpn-service* [vpn-id]
               ...
               +--rw vpn-nodes
                  +--rw vpn-node* [vpn-node-id]
                     +--rw vpn-node-id            vpn-common:vpn-id
                     +--rw description?           string
                     +--rw ne-id?                 string
                     +--rw role?                  identityref
                     +--rw router-id?             rt-types:router-id
                     +--rw active-global-parameters-profiles
                     |  +--rw global-parameters-profile* [profile-id]
                     |     +--rw profile-id                  leafref
                     |     +--rw local-autonomous-system?
                     |     |       inet:as-number
                     |     +--rw svc-mtu?                    uint32
                     |     +--rw ce-vlan-preservation?       boolean
                     |     +--rw ce-vlan-cos-perservation?   boolean
                     |     +--rw control-word-negotiation?   boolean
                     |     +--rw mac-policies
                     |     |  +--rw mac-addr-limit
                     |     |  |  +--rw mac-num-limit?   uint16
                     |     |  |  +--rw time-interval?   uint32
                     |     |  |  +--rw action?          identityref
                     |     |  +--rw mac-loop-prevention
                     |     |     +--rw window?            uint32
                     |     |     +--rw frequency?         uint32
                     |     |     +--rw retry-timer?       uint32
                     |     |     +--rw protection-type?   identityref
                     |     +--rw multicast-like {vpn-common:multicast}?
                     |        +--rw enabled?                 boolean
                     |        +--rw customer-tree-flavors
                     |           +--rw tree-flavor*   identityref
                     +--rw status
                     |  ...
                     +--rw bgp-auto-discovery
                     |  ...
                     +--rw signaling-option
                     |  ...
                     +--rw vpn-network-accesses
                        ...

                        Figure 8: VPN Nodes Subtree

Barguil, et al.         Expires January 29, 2022               [Page 24]
Internet-Draft                    L2NM                         July 2021

   In reference to the subtree shown in Figure 8, the description of VPN
   node data nodes is as follows:

   'vpn-node-id':  Is an identifier that uniquely identifies a node that
      enables a VPN network access.

   'description':  Provides a textual description of the VPN node.

   'ne-id':  Includes a unique identifier of the network element where
      the VPN node is deployed.

   'router-id':  Indicates a 32-bit number that is used to uniquely
      identify a router within an Autonomous System.

   'active-global-parameters-profiles':  Lists the set of active global
      VPN parameters profiles for this VPN node.  Concretely, one or
      more global profiles that are defined at the VPN service level can
      be activated at the VPN node level; each of these profiles is
      uniquely identified by means of 'profile-id'.  The structure of
      'active-global-parameters-profiles' uses the same data nodes as
      Section 6.5 except RD and RT related data nodes.

      Values defined in 'active-global-parameters-profiles' overrides
      the ones defined in the VPN service level.

   'signaling-option':  See Section 6.6.2.

   'status':  Tracks the status of a node involved in a VPN service.
      Both operational and administrative status are maintained.  A
      mismatch between the administrative status vs. the operational
      status can be used as a trigger to detect anomalies.

   'vpn-network-accesses':  Represents the point to which sites are
      connected.

      Note that, unlike in L2SM, the L2NM does not need to model the
      customer site, only the points where the traffic from the site are
      received (i.e., the PE side of PE-CE connections).  Hence, the VPN
      network access contains the connectivity information between the
      provider's network and the customer premises.  The VPN profiles
      ('vpn-profiles') have a set of routing policies that can be
      applied during the service creation.

      See Section 6.7 for more details.

Barguil, et al.         Expires January 29, 2022               [Page 25]
Internet-Draft                    L2NM                         July 2021

6.6.1.  BGP Auto-Discovery

   'bgp-auto-discovery' container (Figure 9) includes the required
   information for the activation of BGP auto-discovery
   [RFC4761][RFC6624].  As discussed in Section 1 of [RFC6624], all of
   BGP-based methods include the notion of a VPN identifier that serves
   to unify components of a given VPN and the concept of auto-discovery;
   hence the support of the data node 'vpn-id'.

   For the particular case of EVPN, the L2NM supports RT auto-derivation
   based on the Ethernet Tag ID specified in Section 7.10.1 of
   [RFC7432].  A VPN service provider can enable/disable this
   functionality by means of 'auto-rt-enable'.  The asigned RT can be
   retrieved using 'auto-route-target'.

   For all BGP-based L2VPN flavors, other data nodes such as RD and RT
   are used.  These data nodes have the same structure as the one
   discussed in Section 6.5.

     +--rw l2vpn-ntw
        +--rw vpn-profiles
        |  ...
        +--rw ethernet-segments
        |  ...
        +--rw vpn-services
           +--rw vpn-service* [vpn-id]
              ...
              +--rw vpn-nodes
                 +--rw vpn-node* [vpn-node-id]
                    ...
                    +--rw bgp-auto-discovery
                    |  +--rw (bgp-type)?
                    |  |  +--:(l2vpn-bgp)
                    |  |  |  +--rw vpn-id?
                    |  |  |          vpn-common:vpn-id
                    |  |  +--:(evpn-bgp)
                    |  |     +--rw evpn-type?           identityref
                    |  |     +--rw auto-rt-enable?      boolean
                    |  |     +--ro auto-route-target?
                    |  |             rt-types:route-target
                    |  +--rw (rd-choice)?
                    |  |  +--:(directly-assigned)
                    |  |  |  +--rw rd?
                    |  |  |          rt-types:route-distinguisher
                    |  |  +--:(directly-assigned-suffix)
                    |  |  |  +--rw rd-suffix?           uint16
                    |  |  +--:(auto-assigned)
                    |  |  |  +--rw rd-auto

Barguil, et al.         Expires January 29, 2022               [Page 26]
Internet-Draft                    L2NM                         July 2021

                    |  |  |     +--rw (auto-mode)?
                    |  |  |     |  +--:(from-pool)
                    |  |  |     |  |  +--rw rd-pool-name?   string
                    |  |  |     |  +--:(full-auto)
                    |  |  |     |     +--rw auto?           empty
                    |  |  |     +--ro auto-assigned-rd?
                    |  |  |             rt-types:route-distinguisher
                    |  |  +--:(auto-assigned-suffix)
                    |  |  |  +--rw rd-auto-suffix
                    |  |  |     +--rw (auto-mode)?
                    |  |  |     |  +--:(from-pool)
                    |  |  |     |  |  +--rw rd-pool-name?        string
                    |  |  |     |  +--:(full-auto)
                    |  |  |     |     +--rw auto?                empty
                    |  |  |     +--ro auto-assigned-rd-suffix?   uint16
                    |  |  +--:(no-rd)
                    |  |     +--rw no-rd?               empty
                    |  +--rw vpn-target* [id]
                    |  |  +--rw id                   int8
                    |  |  +--rw route-targets* [route-target]
                    |  |  |  +--rw route-target    rt-types:route-target
                    |  |  +--rw route-target-type
                    |  |          rt-types:route-target-type
                    |  +--rw vpn-policies
                    |     +--rw import-policy?   string
                    |     +--rw export-policy?   string
                    +--rw signaling-option
                    |  ...
                    +--rw vpn-network-accesses
                       ...

                   Figure 9: BGP Auto-Discovery Subtree

6.6.2.  Signaling Options

   The 'signaling-option' container (Figure 10) defines a set of data
   nodes for a given signaling protocol that is used for an L2VPN
   service.  As discussed in Section 6.4, several signaling options to
   exchange membership information between PEs of an L2VPN are
   supported.  The signaling type to be used for an L2VPN service is the
   controlled at the VPN service level by means of 'signaling-type'.

Barguil, et al.         Expires January 29, 2022               [Page 27]
Internet-Draft                    L2NM                         July 2021

         ...
         +--rw vpn-nodes
            +--rw vpn-node* [vpn-node-id]
            ...
            +--rw signaling-option
            |  +--rw mtu-pw?               uint16
            |  +--rw mtu-allow-mismatch?   boolean
            |  +--rw type?                                 leafref
            |  +--rw (signaling-option)?
            |     +--:(bgp)
            |     |  ...
            |     +--:(ldp-or-l2tp)
            |           +--rw (ldp-or-l2tp)?
            |              +--:(ldp)
            |              |  ...
            |              +--:(l2tp)
            |                 ...

                Figure 10: Signaling Option Overall Subtree

   The following signaling data nodes are supported:

   'mtu':  Sets the MTU to advertise for a PW (e.g., Section 5.1 of
      [RFC6624] or Section 6.1 of [RFC4762]).

   'mtu-allow-mismatch':  When set to true, it allows MTU mismatch for a
      PW (see, e.g., Section 4.3 of [RFC4667]).

   'type':  Indicates the signaling type.  This type inherits the value
      of 'signaling-type' defined at the service level (Section 6.4).

   'bgp':  Is provided when BGP is used for L2VPN signaling.  The
      structure of the BGP-related data nodes is provided in Figure 11.

      As discussed in Section 2.2.2 of [RFC6624], a CE ID ('ce-id')
      identifying the CE within the VPN must be provided.  Remote CEs
      that are entitled to connect to the same VPN should fit with the
      CE range ('ce-range') as discussed in Section 2.2.3 of [RFC6624].
      'pw-encapsulation-type' is used to control the PW encapsulation
      type (Section 3 of [RFC6624]).  The value of the 'pw-
      encapsulation-type' are taken from the IANA-maintained "iana-bgp-
      l2-encaps" module.

      For the specific case of VPLS, the VPLS Edge ID (VE ID, 'vpls-
      edge-id') and a VE ID range ('vpls-edge-id-range') are provided as
      per Section 3.2 of [RFC4761].

Barguil, et al.         Expires January 29, 2022               [Page 28]
Internet-Draft                    L2NM                         July 2021

      For EVPN-related L2VPNs, 'service-interface-type' indicates
      whether this is VLAN-based, VLAN bundle, or VLAN-aware bundle
      service interface (Section 6 of [RFC7432]).  Moreover, a set of
      policies can be provided such as MAC address learning mode,
      ingress replication, Address Resolution Protocol (ARP) and
      Nighbour Discovery (ND) proxy, processing of Broadcast, unknown
      unicast, or multicast (BUM), etc.

         ...
         |  +--rw (signaling-option)?
         |     ...
         |     +--:(bgp)
         |     |  +--rw (bgp-type)?
         |     |     +--:(l2vpn-bgp)
         |     |     |  +--rw ce-id?        uint16
         |     |     |  +--rw ce-range?     uint16
         |     |     |  +--rw pw-encapsulation-type?
         |     |     |  |       identityref
         |     |     |  +--rw vpls-instance
         |     |     |     +--rw vpls-edge-id?         uint16
         |     |     |     +--rw vpls-edge-id-range?   uint16
         |     |     +--:(evpn-bgp)
         |     |        +--rw evpn-type?                leafref
         |     |        +--rw service-interface-type?
         |     |        |       identityref
         |     |        +--rw evpn-policies
         |     |           +--rw mac-learning-mode?
         |     |           |       identityref
         |     |           +--rw ingress-replication?
         |     |           |       boolean
         |     |           +--rw p2mp-replication?
         |     |           |       boolean
         |     |           +--rw arp-proxy {vpn-common:ipv4}?
         |     |           |  +--rw enable?           boolean
         |     |           |  +--rw arp-suppression?
         |     |           |  |       boolean
         |     |           |  +--rw ip-mobility-threshold?
         |     |           |  |       uint16
         |     |           |  +--rw duplicate-ip-detection-interval?
         |     |           |          uint16
         |     |           +--rw nd-proxy {vpn-common:ipv6}?
         |     |           |  +--rw enable?  |       boolean
         |     |           |  +--rw nd-suppression?
         |     |           |  |       boolean
         |     |           |  +--rw ip-mobility-threshold?
         |     |           |  |       uint16
         |     |           |  +--rw duplicate-ip-detection-interval?
         |     |           |          uint16

Barguil, et al.         Expires January 29, 2022               [Page 29]
Internet-Draft                    L2NM                         July 2021

         |     |           +--rw underlay-multicast?
         |     |           |       boolean
         |     |           +--rw flood-unknown-unicast-supression?
         |     |           |       boolean
         |     |           +--rw vpws-vlan-aware?        boolean
         |     |           +--rw bum-management
         |     |           |  +--rw discard-broadcast?
         |     |           |  |       boolean
         |     |           |  +--rw discard-unknown-multicast?
         |     |           |  |       boolean
         |     |           |  +--rw discard-unknown-unicast?
         |     |           |          boolean
         |     |           +--rw pbb
         |     |              +--rw backbone-src-mac?
         |     |                      yang:mac-address
         |     +--:(ldp-or-l2tp)
         |        ...

                 Figure 11: Signaling Option Subtree (BGP)

   'ldp':  The model supports the configuration of the parameters that
      are discussed in Section 6 of [RFC4762].  Such parameters include
      a an Attachment Group Identifier (AGI) (a.k.a., VPLS-id), a Source
      Attachment Individual Identifier (SAII), a list of peers that are
      associated with a Target Attachment Individual Identifier (TAII),
      a PW type, and a PW description, (Figure 12).  Unlike BGP, only
      Ethernet and Ethernet tagged mode are supported.  The AGI, SAII,
      and TAII are encoded following the types defined in Section 3.4 of
      [RFC4446].

Barguil, et al.         Expires January 29, 2022               [Page 30]
Internet-Draft                    L2NM                         July 2021

             ...
             |  +--rw (signaling-option)?
             |     ...
             |     +--:(bgp)
             |     |  ...
             |     +--:(ldp-or-l2tp)
             |        +--rw ldp-or-l2tp
             |           +--rw agi?
             |           |       rt-types:route-distinguisher
             |           +--rw saii?                      uint32
             |           +--rw remote-targets* [taii]
             |           |  +--rw taii         uint32
             |           |  +--rw peer-addr    inet:ip-address
             |           +--rw (ldp-or-l2tp)?
             |              +--:(ldp)
             |              |  +--rw t-ldp-pw-type?
             |              |  |       identityref
             |              |  +--rw pw-type?       identityref
             |              |  +--rw pw-description?      string
             |              |  +--rw mac-addr-withdraw?   boolean
             |              |  +--rw pw-peer-list*
             |              |  |       [peer-addr vc-id]
             |              |  |  +--rw peer-addr
             |              |  |  |       inet:ip-address
             |              |  |  +--rw vc-id   string
             |              |  |  +--rw pw-priority?   uint32
             |              |  +--rw qinq
             |              |     +--rw s-tag?   uint32
             |              |     +--rw c-tag?   uint32
             |              +--:(l2tp)
             |                 +--rw router-id?
             |                 |       rt-types:router-id
             |                 +--rw pseudowire-type?
             |                         identityref
             ...

                 Figure 12: Signaling Option Subtree (LDP)

   'l2tp':  The model supports the configuration of the parameters that
      are discussed in Section 4 of [RFC4667].  Such parameters include
      a router-id that is used to uniquely identify a PE, a PW type, an
      AGI, an SAII, and a list of peers that are associated with a TAII
      (Figure 13).  The PW type ('pseudowire-type') value is taken from
      the IANA-maintained "iana-pseudowire-types" module.

Barguil, et al.         Expires January 29, 2022               [Page 31]
Internet-Draft                    L2NM                         July 2021

             ...
             |  +--rw (signaling-option)?
             |     ...
             |     +--:(bgp)
             |     |  ...
             |     +--:(ldp-or-l2tp)
             |        +--rw ldp-or-l2tp
             |           +--rw agi?
             |           |       rt-types:route-distinguisher
             |           +--rw saii?                      uint32
             |           +--rw remote-target* [peer-addr taii]
             |           |  +--rw peer-addr    inet:ip-address
             |           |  +--rw taii         uint32
             |           +--rw (ldp-or-l2tp)?
             |              +--:(ldp)
             |              |  ...
             |              +--:(l2tp)
             |                 +--rw router-id?
             |                 |       rt-types:router-id
             |                 +--rw pseudowire-type?
             |                         identityref
             ...

                Figure 13: Signaling Option Subtree (L2TP)

6.7.  VPN Network Access

   A 'vpn-network-access' represents an entry point to a VPN service .
   In other words, this container encloses the parameters that describe
   the access information for the traffic that belongs to a particular
   L2VPN.  As such, every 'vpn-network-access' MUST belong to one and
   only one 'vpn-node'.

   A 'vpn-network-access' includes information such as the connection on
   which the access is defined , the specific layer 2 service
   requirements, etc.

   The VPN network access is comprised of:

   'id':  Includes an identifier of the VPN network access.

   'description':  Includes a textual description of the VPN network
      access.

   'port-id':  Indicates the port on which the VPN network access is
      bound.

Barguil, et al.         Expires January 29, 2022               [Page 32]
Internet-Draft                    L2NM                         July 2021

   ' global-parameters-profile':  Provides a pointer to an active
      'global-parameters-profile' at the VPN node level.  Referencing an
      active 'global-parameters-profile' implies that all associated
      data nodes will be inherited by the VPN network access.  However,
      some of the inherited data nodes (e.g., ACL policies) can be
      refined at the VPN network access level.  In such case, refined
      values take precedence over inherited ones.

   'status':  Indicates the administrative and operational status of the
      service.

   'connection':  Represents and groups the set of Layer 2 connectivity
      from where the traffic of the L2VPN in a particular VPN Network
      access is coming.  See Section 6.7.1.

   'vpws-service-instance':  Includes a set of data nodes that are
      required for the configuration of a VPWS-EVPN [RFC8214].  See
      Section 6.7.2.

   'group':  Is used for grouping VPN network accesses by assigning the
      same identifier to these accesses.  The precedence attribute is
      used to differentiate the primary and secondary accesses for a
      service with multiple accesses.  An example to illustrate the use
      of this container for redundancy purposes is provided in
      Appendix A.6.  This container is also used to identify the link of
      an ES by allocating the same ESI.  An example to illustrate this
      functionality is provided in Appendices A.4 and A.5.

   'ethernet-service-oam':  Carries information about the service OAM.
      See Section 6.7.3.

   'service':  Specifies the service parameters (e.g., QoS, multicast)
      to apply for a given VPN network access.  See Section 6.7.4.

Barguil, et al.         Expires January 29, 2022               [Page 33]
Internet-Draft                    L2NM                         July 2021

           ...
           +--rw vpn-nodes
              +--rw vpn-node* [vpn-node-id]
                 ...
                 +--rw vpn-network-accesses
                    +--rw vpn-network-access* [id]
                       +--rw id                        vpn-common:vpn-id
                       +--rw description?              string
                       +--rw interface-id?             string
                       +--rw global-parameters-profile?   leafref
                       +--rw status
                       |  ...
                       +--rw connection
                       |  ...
                       +--rw vpws-service-instance
                       |  ...
                       +--rw group* [group-id]
                       |  +--rw group-id                       string
                       |  +--rw group-color?                   string
                       |  +--rw precedence?
                       |  |       identityref
                       |  +--rw ethernet-segment-identifier?   leafref
                       +--rw ethernet-service-oam
                       |  ...
                       +--rw service
                          ...

                   Figure 14: VPN Network Access Subtree

6.7.1.  Connection

   The 'connection' container (Figure 15) is used to configure the
   relevant properties of the interface to which the L2VPN instance is
   attached to (e.g., encapsulation type, lag interfaces, split-
   horizon).  The L2NM supports tag manipulation operations (e.g., tag
   rewrite).

   Note that the 'connection' container does not include the physical-
   specific configuration as this is assumed to be directly handled
   using device modules (e.g., interfaces module).  Moreover, this
   design is also meant to avoid manipulated global parameters at the
   service level and lower the risk of impacting other services sharing
   the same physical interface.

   Some consistency checks should be ensured by implementations for LAG
   interface as the same information (e.g., LACP system-id) should be
   provided to the involved nodes.

Barguil, et al.         Expires January 29, 2022               [Page 34]
Internet-Draft                    L2NM                         July 2021

              ...
              +--rw vpn-nodes
                 +--rw vpn-node* [vpn-node-id]
                    ...
                    +--rw vpn-network-accesses
                       +--rw vpn-network-access* [id]
                          ...
                          +--rw connection
                          |  +--rw l2-termination-point?
                          |  |       string
                          |  +--rw local-bridge-reference?
                          |  |       string
                          |  +--rw bearer-reference?         string
                          |  |       {vpn-common:bearer-reference}?
                          |  +--rw encapsulation
                          |  |  +--rw type?              identityref
                          |  |  +--rw dot1q {vpn-common:dot1q}?
                          |  |  |  +--rw tag-type?   identityref
                          |  |  |  +--rw cvlan-id?   uint16
                          |  |  |  +--rw rewrite
                          |  |  |     +--rw (tag-choice)?
                          |  |  |     |  +--:(pop)
                          |  |  |     |  |  +--rw pop?
                          |  |  |     |  |          enumeration
                          |  |  |     |  +--:(push)
                          |  |  |     |  |  +--rw push?        empty
                          |  |  |     |  +--:(translate)
                          |  |  |     |     +--rw translate?
                          |  |  |     |             enumeration
                          |  |  |     +--rw cvlan-id?          uint16
                          |  |  |     +--rw mode?         enumeration
                          |  |  +--rw priority-tagged
                          |  |  |  +--rw tag-type?   identityref
                          |  |  +--rw qinq {vpn-common:qinq}?
                          |  |     +--rw tag-type?   identityref
                          |  |     +--rw svlan-id    uint16
                          |  |     +--rw cvlan-id    uint16
                          |  +--rw lag-interface
                          |          {vpn-common:lag-interface}?
                          |     +--rw lag-interface*
                          |     |       [lag-interface-number]
                          |     |  +--rw lag-interface-number    uint32
                          |     |  +--rw lacp
                          |     |     +--rw lacp-state?         boolean
                          |     |     +--rw lacp-mode?          boolean
                          |     |     +--rw lacp-speed?         boolean
                          |     |     +--rw mini-link?          uint32
                          |     |     +--rw system-id?

Barguil, et al.         Expires January 29, 2022               [Page 35]
Internet-Draft                    L2NM                         July 2021

                          |     |     |       yang:mac-address
                          |     |     +--rw admin-key?          uint16
                          |     |     +--rw system-priority?    uint16
                          |     |     +--rw member-link-list
                          |     |     |  +--rw member-link* [name]
                          |     |     |     +--rw name          string
                          |     |     |     +--rw port-speed?   uint32
                          |     |     |     +--rw mode?    identityref
                          |     |     |     +--rw link-mtu?     uint32
                          |     |     |     +--rw oam-802.3ah-link
                          |     |     |             {oam-3ah}?
                          |     |     |        +--rw enable?   boolean
                          |     |     +--rw flow-control?       string
                          |     |     +--rw lldp?               boolean
                          |     +--rw split-horizon
                          |        +--rw group-name?   string
                          ...

                       Figure 15: Connection Subtree

6.7.2.  EVPN-VPWS Service Instance

   The 'vpws-service-instance' provides the local and remote VPWS
   Service Instance (VSI) [RFC8214].  This container is only present
   when the 'vpn-type' is VPWS-EVPN.  As shown in Figure 16, the VSIs
   can be configured by a VPN service provider or auto-generated.

   An example to illustrate the use of the L2NM to configure VPWS-EVPN
   instances is provided in Appendix A.4.

Barguil, et al.         Expires January 29, 2022               [Page 36]
Internet-Draft                    L2NM                         July 2021

              ...
              +--rw vpn-nodes
                 +--rw vpn-node* [vpn-node-id]
                    ...
                    +--rw vpn-network-accesses
                       +--rw vpn-network-access* [id]
                          ...
                          +--rw vpws-service-instance
                          |  +--rw (local-vsi-choice)?
                          |  |  +--:(directly-assigned)
                          |  |  |  +--rw local-vpws-service-instance?
                          |  |  |          uint32
                          |  |  +--:(auto-assigned)
                          |  |     +--rw local-vsi-auto
                          |  |        +--rw (auto-mode)?
                          |  |        |  +--:(from-pool)
                          |  |        |  |  +--rw vsi-pool-name?
                          |  |        |  |          string
                          |  |        |  +--:(full-auto)
                          |  |        |     +--rw auto?            empty
                          |  |        +--ro auto-local-vsi?
                          |  |                uint32
                          |  +--rw (remote-vsi-choice)?
                          |     +--:(directly-assigned)
                          |     |  +--rw remote-vpws-service-instance?
                          |     |          uint32
                          |     +--:(auto-assigned)
                          |        +--rw remote-vsi-auto
                          |           +--rw (auto-mode)?
                          |           |  +--:(from-pool)
                          |           |  |  +--rw vsi-pool-name?
                          |           |  |          string
                          |           |  +--:(full-auto)
                          |           |     +--rw auto?            empty
                          |           +--ro auto-remote-vsi?
                          |                   uint32
                          ...

               Figure 16: EVPN-VPWS Service Instance Subtree

6.7.3.  Ethernet OAM

   Ethernet OAM refers to both [IEEE-802-1ag] and [ITU-T-Y-1731].

   As shown in Figure 17, the L2NM inherits the same structure as in
   Section 5.3.2.2.6 of [RFC8466] for OAM matters.

       +--rw l2vpn-ntw

Barguil, et al.         Expires January 29, 2022               [Page 37]
Internet-Draft                    L2NM                         July 2021

          +--rw vpn-profiles
          |  ...
          +--rw ethernet-segments
          |  ...
          +--rw vpn-services
             +--rw vpn-service* [vpn-id]
                ...
                +--rw vpn-nodes
                   +--rw vpn-node* [vpn-node-id]
                      ...
                      +--rw vpn-network-accesses
                         +--rw vpn-network-access* [id]
                            ...
                            +--rw ethernet-service-oam
                            |  +--rw md-name?        string
                            |  +--rw md-level?       uint8
                            |  +--rw cfm-802.1-ag
                            |  |  +--rw n2-uni-c* [maid]
                            |  |  |  +--rw maid                string
                            |  |  |  +--rw mep-id?             uint32
                            |  |  |  +--rw mep-level?          uint32
                            |  |  |  +--rw mep-up-down?
                            |  |  |  |                   enumeration
                            |  |  |  +--rw remote-mep-id?      uint32
                            |  |  |  +--rw cos-for-cfm-pdus?   uint32
                            |  |  |  +--rw ccm-interval?       uint32
                            |  |  |  +--rw ccm-holdtime?       uint32
                            |  |  |  +--rw ccm-p-bits-pri?
                            |  |  |          ccm-priority-type
                            |  |  +--rw n2-uni-n* [maid]
                            |  |     +--rw maid                string
                            |  |     +--rw mep-id?             uint32
                            |  |     +--rw mep-level?          uint32
                            |  |     +--rw mep-up-down?
                            |  |     |                    enumeration
                            |  |     +--rw remote-mep-id?      uint32
                            |  |     +--rw cos-for-cfm-pdus?   uint32
                            |  |     +--rw ccm-interval?       uint32
                            |  |     +--rw ccm-holdtime?       uint32
                            |  |     +--rw ccm-p-bits-pri?
                            |  |             ccm-priority-type
                            |  +--rw y-1731* [maid]
                            |     +--rw maid               string
                            |     +--rw mep-id?            uint32
                            |     +--rw type?              identityref
                            |     +--rw remote-mep-id?     uint32
                            |     +--rw message-period?    uint32
                            |     +--rw measurement-interval?   uint32

Barguil, et al.         Expires January 29, 2022               [Page 38]
Internet-Draft                    L2NM                         July 2021

                            |     +--rw cos?        uint32
                            |     +--rw loss-measurement?      boolean
                            |     +--rw synthethic-loss-measurement?
                            |     |       boolean
                            |     +--rw delay-measurement
                            |     |  +--rw enable-dm?   boolean
                            |     |  +--rw two-way?     boolean
                            |     +--rw frame-size?     uint32
                            |     +--rw session-type?   enumeration
                            ...

                          Figure 17: OAM Subtree

6.7.4.  Services

   The 'service' container (Figure 18) provides a set of service-
   specific configuration such as Quality of Service (QoS).

      +--rw l2vpn-ntw
         +--rw vpn-profiles
         |  ...
         +--rw ethernet-segments
         |  ...
         +--rw vpn-services
            +--rw vpn-service* [vpn-id]
               ...
               +--rw vpn-nodes
                  +--rw vpn-node* [vpn-node-id]
                     ...
                     +--rw vpn-network-accesses
                        +--rw vpn-network-access* [id]
                           ...
                           +--rw service
                              +--rw mtu?            uint32
                              +--rw svc-inbound-bandwidth
                              |  ...
                              +--rw svc-outbound-bandwidth
                              |  ...
                              +--rw qos {vpn-common:qos}?
                              |  ...
                              +--rw mac-policies
                              |  ...
                              +--rw broadcast-unknown-unicast-multicast
                                 ...

                    Figure 18: Service Overall Subtree

   The description of the service data nodes is as follows:

Barguil, et al.         Expires January 29, 2022               [Page 39]
Internet-Draft                    L2NM                         July 2021

   'mtu':  Specifies the MTU for the VPN network access.

   'svc-inbound-bandwidth' and 'svc-outbound-bandwidth':  Specify the
      service bandwidth for the L2VPN service.  It can be represented
      using the Committed Information Rate (CIR), the Excess Information
      Rate (EIR), or the Peak Information Rate (PIR).  As shown in
      Figure 19, the structure of service bandwidth data nodes is
      inherited from the L2SM [RFC8466].  The following types, defined
      in [I-D.ietf-opsawg-vpn-common], can be used to indicate the
      bandwidth type:

      'bw-per-cos':  The bandwidth is per Class of Service (CoS).

      'bw-per-port':  The bandwidth is per VPN network access.

      'bw-per-site':  The bandwidth is to all VPN network accesses that
         belong to the same site.

      'bw-per-service':  The bandwidth is per L2VPN service.

      'svc-inbound-bandwidth' indicates the inbound bandwidth of the
      connection (i.e., download bandwidth from the service provider to
      the site).

      'svc-outbound-bandwidth' indicates the outbound bandwidth of the
      connection (i.e., upload bandwidth from the site to the service
      provider).

Barguil, et al.         Expires January 29, 2022               [Page 40]
Internet-Draft                    L2NM                         July 2021

                              +--rw service
                                 ...
                                 +--rw svc-inbound-bandwidth
                                 |       {vpn-common:inbound-bw}?
                                 |  +--rw inbound-bandwidth* [type]
                                 |     +--rw type      identityref
                                 |     +--rw cos-id?   uint8
                                 |     |       {vpn-common:qos}?
                                 |     +--rw cir?      uint64
                                 |     +--rw cbs?      uint64
                                 |     +--rw eir?      uint64
                                 |     +--rw ebs?      uint64
                                 |     +--rw pir?      uint64
                                 |     +--rw pbs?      uint64
                                 +--rw svc-outbound-bandwidth
                                 |       {vpn-common:outbound-bw}?
                                 |  +--rw outbound-bandwidth* [type]
                                 |     +--rw type      identityref
                                 |     +--rw cos-id?   uint8
                                 |     |       {vpn-common:qos}?
                                 |     +--rw cir?      uint64
                                 |     +--rw cbs?      uint64
                                 |     +--rw eir?      uint64
                                 |     +--rw ebs?      uint64
                                 |     +--rw pir?      uint64
                                 |     +--rw pbs?      uint64
                                 ...

                   Figure 19: Service Bandwidth Subtree

   QoS  Is used to define a set of QoS policies to apply on a given VPN
      network access (Figure 20).  The QoS classification can be based
      on many criteria such as source MAC address, destination MAC
      address, etc.

Barguil, et al.         Expires January 29, 2022               [Page 41]
Internet-Draft                    L2NM                         July 2021

                          +--rw service
                             ...
                             +--rw qos {vpn-common:qos}?
                             |  +--rw qos-classification-policy
                             |  |  +--rw rule* [id]
                             |  |     +--rw id                string
                             |  |     +--rw (match-type)?
                             |  |     |  +--:(match-flow)
                             |  |     |  |  +--rw match-flow
                             |  |     |  |     +--rw dscp?   inet:dscp
                             |  |     |  |     +--rw dot1q?     uint16
                             |  |     |  |     +--rw pcp?       uint8
                             |  |     |  |     +--rw src-mac-address?
                             |  |     |  |     |       yang:mac-address
                             |  |     |  |     +--rw dst-mac-address?
                             |  |     |  |     |       yang:mac-address
                             |  |     |  |     +--rw color-type?
                             |  |     |  |     |       identityref
                             |  |     |  |     +--rw any?         empty
                             |  |     |  +--:(match-application)
                             |  |     |     +--rw match-application?
                             |  |     |             identityref
                             |  |     +--rw target-class-id?     string
                             |  +--rw qos-profile
                             |     +--rw qos-profile* [profile]
                             |        +--rw profile      leafref
                             |        +--rw direction?   identityref
                             ...

                          Figure 20: QoS Subtree

   'mac-policies':  Lists a set of MAC-related policies such as MAC
      ACLs.  An ACL can be based on source MAC address, source MAC
      address mask, destination MAC address , and destination MAC
      address mask.  A data frame that matches an ACL can be dropped,
      flooded, or trigger an alarm.  A rate-limit policy can be defined
      for handling frames that match an ACL entry with 'flood' action.

      When 'mac-loop-prevention' or 'mac-addr-limit' data nodes are
      provided, they take precendence over the one inlcudes at the
      'global-parameters-profile' at the VPN service or VPN node levels.

Barguil, et al.         Expires January 29, 2022               [Page 42]
Internet-Draft                    L2NM                         July 2021

                          +--rw service
                             ...
                             +--rw mac-policies
                             |  +--rw access-control-list* [name]
                             |  |  +--rw name                    string
                             |  |  +--rw src-mac-address*
                             |  |  |       yang:mac-address
                             |  |  +--rw src-mac-address-mask*
                             |  |  |       yang:mac-address
                             |  |  +--rw dst-mac-address*
                             |  |  |       yang:mac-address
                             |  |  +--rw dst-mac-address-mask*
                             |  |  |       yang:mac-address
                             |  |  +--rw action?          identityref
                             |  |  +--rw rate-limit?      decimal64
                             |  +--rw mac-loop-prevention
                             |  |  +--rw window?            uint32
                             |  |  +--rw frequency?         uint32
                             |  |  +--rw retry-timer?       uint32
                             |  |  +--rw protection-type?   identityref
                             |  +--rw mac-addr-limit
                             |     +--rw mac-num-limit?   uint16
                             |     +--rw time-interval?   uint32
                             |     +--rw action?          identityref
                             ...

                      Figure 21: MAC Policies Subtree

   'broadcast-unknown-unicast-multicast':  Defines the type of site in
      the customer multicast service topology: source, receiver, or
      both.  It is also used to define multicast group-to-port mappings.

                          +--rw service
                             ...
                             +--rw broadcast-unknown-unicast-multicast
                                +--rw multicast-site-type?
                                |       enumeration
                                +--rw multicast-gp-address-mapping* [id]
                                |  +--rw id                 uint16
                                |  +--rw vlan-id?           uint32
                                |  +--rw mac-gp-address?
                                |  |       yang:mac-address
                                |  +--rw port-lag-number?   uint32
                                +--rw bum-overall-rate?     uint32

                          Figure 22: BUM Subtree

Barguil, et al.         Expires January 29, 2022               [Page 43]
Internet-Draft                    L2NM                         July 2021

7.  YANG Modules

7.1.  IANA BGP Layer 2 Encapsulation Types

   The "iana-bgp-l2-encaps" YANG module (Section 7.1) is designed to
   echo the registry available at [IANA-BGP-L2].  Appendix B lists the
   initial values included in the "iana-bgp-l2-encaps" YANG module.

<CODE BEGINS>file "iana-bgp-l2-encaps@2021-07-05.yang"
module iana-bgp-l2-encaps {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps";
  prefix iana-bgp-l2-encaps;

  organization
    "IANA";
  contact
    "Internet Assigned Numbers Authority

     Postal: ICANN
          12025 Waterfront Drive, Suite 300
          Los Angeles, CA  90094-2536
          United States of America
     Tel:    +1 310 301 5800
     <mailto:iana@iana.org>";
  description
    "This module contains a collection of YANG data types defined
     by IANA and used for referring to BGP layer 2 encapsulation
     types.

     Copyright (c) 2021 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Simplified BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (http://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX; see
     the RFC itself for full legal notices.";

  revision 2021-07-05 {
    description
      "First revision.";
    reference
      "RFC XXXX: A Layer 2 VPN Network YANG Model.";

Barguil, et al.         Expires January 29, 2022               [Page 44]
Internet-Draft                    L2NM                         July 2021

  }

  identity bgp-l2-encaps-type {
    description
      "Base BGP Layer 2 encapsulation type.";
    reference
      "RFC 6624: Layer 2 Virtual Private Networks Using BGP for
                 Auto-Discovery and Signaling";
  }

  identity frame-relay {
    base bgp-l2-encaps-type;
    description
      "Frame Relay.";
    reference
      "RFC 4446: IANA Allocations for Pseudowire Edge
                 to Edge Emulation (PWE3)";
  }

  identity atm-aal5 {
    base bgp-l2-encaps-type;
    description
      "ATM AAL5 SDU VCC transport.";
    reference
      "RFC 4446: IANA Allocations for Pseudowire Edge
                 to Edge Emulation (PWE3)";
  }

  identity atm-cell {
    base bgp-l2-encaps-type;
    description
      "ATM transparent cell transport";
    reference
      "RFC 4816: Pseudowire Emulation Edge-to-Edge (PWE3)
                 Asynchronous Transfer Mode (ATM) Transparent
                 Cell Transport Service";
  }

  identity ethernet-tagged-mode {
    base bgp-l2-encaps-type;
    description
      "Ethernet (VLAN) Tagged Mode.";
    reference
      "RFC 4448: Encapsulation Methods for Transport of Ethernet
                 over MPLS Networks";
  }

  identity ethernet-raw-mode {

Barguil, et al.         Expires January 29, 2022               [Page 45]
Internet-Draft                    L2NM                         July 2021

    base bgp-l2-encaps-type;
    description
      "Ethernet Raw Mode.";
    reference
      "RFC 4448: Encapsulation Methods for Transport of Ethernet
                 over MPLS Networks";
  }

  identity hdlc {
    base bgp-l2-encaps-type;
    description
      "Cisco HDLC.";
    reference
      "RFC 4618: Encapsulation Methods for Transport of
                 PPP/High-Level Data Link Control (HDLC)
                 over MPLS Networks";
  }

  identity ppp {
    base bgp-l2-encaps-type;
    description
      "PPP.";
    reference
      "RFC 4618: Encapsulation Methods for Transport of
                 PPP/High-Level Data Link Control (HDLC)
                 over MPLS Networks";
  }

  identity circuit-emulation {
    base bgp-l2-encaps-type;
    description
      "SONET/SDH Circuit Emulation Service.";
    reference
      "RFC 4842: Synchronous Optical Network/Synchronous Digital
                 Hierarchy (SONET/SDH) Circuit Emulation over Packet
                 (CEP)";
  }

  identity atm-to-vcc {
    base bgp-l2-encaps-type;
    description
      "ATM n-to-one VCC cell transport.";
    reference
      "RFC 4717: Encapsulation Methods for Transport of
                 Asynchronous Transfer Mode (ATM) over MPLS Networks";
  }

  identity atm-to-vpc {

Barguil, et al.         Expires January 29, 2022               [Page 46]
Internet-Draft                    L2NM                         July 2021

    base bgp-l2-encaps-type;
    description
      "ATM n-to-one VPC cell transport.";
    reference
      "RFC 4717: Encapsulation Methods for Transport of
                 Asynchronous Transfer Mode (ATM) over MPLS Networks";
  }

  identity layer-2-transport {
    base bgp-l2-encaps-type;
    description
      "IP Layer 2 Transport.";
    reference
      "RFC 3032: MPLS Label Stack Encoding";
  }

  identity fr-port-mode {
    base bgp-l2-encaps-type;
    description
      "Frame Relay Port mode.";
    reference
      "RFC 4619: Encapsulation Methods for Transport of Frame Relay over
                 Multiprotocol Label Switching (MPLS) Networks";
  }

  identity e1 {
    base bgp-l2-encaps-type;
    description
      "Structure-agnostic E1 over packet.";
    reference
      "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
                 over Packet (SAToP)";
  }

  identity t1 {
    base bgp-l2-encaps-type;
    description
      "Structure-agnostic T1 (DS1) over packet.";
    reference
      "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
                 over Packet (SAToP)";
  }

  identity vpls {
    base bgp-l2-encaps-type;
    description
      "VPLS.";
    reference

Barguil, et al.         Expires January 29, 2022               [Page 47]
Internet-Draft                    L2NM                         July 2021

      "RFC 4761: Virtual Private LAN Service (VPLS)
                 Using BGP for Auto-Discovery and Signaling";
  }

  identity t3 {
    base bgp-l2-encaps-type;
    description
      "Structure-agnostic T3 (DS3) over packet.";
    reference
      "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
                 over Packet (SAToP)";
  }

  identity structure-aware {
    base bgp-l2-encaps-type;
    description
      "Nx64kbit/s Basic Service using Structure-aware.";
    reference
      "RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
                 Circuit Emulation Service over Packet Switched
                 Network (CESoPSN)";
  }

  identity dlci {
    base bgp-l2-encaps-type;
    description
      "Frame Relay DLCI.";
    reference
      "RFC 4619: Encapsulation Methods for Transport of Frame Relay over
                 Multiprotocol Label Switching (MPLS) Networks";
  }

  identity e3 {
    base bgp-l2-encaps-type;
    description
      "Structure-agnostic E3 over packet.";
    reference
      "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
                 over Packet (SAToP)";
  }

  identity ds1 {
    base bgp-l2-encaps-type;
    description
      "Octet-aligned payload for Structure-agnostic DS1 circuits.";
    reference
      "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
                 over Packet (SAToP)";

Barguil, et al.         Expires January 29, 2022               [Page 48]
Internet-Draft                    L2NM                         July 2021

  }

  identity cas {
    base bgp-l2-encaps-type;
    description
      "DS1 (ESF) Nx64kbit/s with CAS using Structure-aware.";
    reference
      "RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
                 Circuit Emulation Service over Packet Switched
                 Network (CESoPSN)";
  }

  identity esf {
    base bgp-l2-encaps-type;
    description
      "DS1 (ESF) Nx64kbit/s with CAS using Structure-aware.";
    reference
      "RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
                 Circuit Emulation Service over Packet Switched
                 Network (CESoPSN)";
  }

  identity sf {
    base bgp-l2-encaps-type;
    description
      "DS1 (SF) Nx64kbit/s with CAS using Structure-aware.";
    reference
      "RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
                 Circuit Emulation Service over Packet Switched
                 Network (CESoPSN)";
  }
}
<CODE ENDS>

7.2.  IANA Encapsulation Types

   The initial version of the "iana-pseudowire-types" YANG module
   (Section 7.2) is designed to echo the registry available at
   [IANA-PW-Types]. . Appendix C lists the initial values included in
   the "iana-bgp-l2-encaps" YANG module.

<CODE BEGINS>file "iana-pseudowire-types@2021-07-05.yang"
module iana-pseudowire-types {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:iana-pseudowire-types";
  prefix iana-pw-types;

  organization

Barguil, et al.         Expires January 29, 2022               [Page 49]
Internet-Draft                    L2NM                         July 2021

    "IANA";
  contact
    "Internet Assigned Numbers Authority

     Postal: ICANN
          12025 Waterfront Drive, Suite 300
          Los Angeles, CA  90094-2536
          United States of America
     Tel:    +1 310 301 5800
     <mailto:iana@iana.org>";
  description
    "This module contains a collection of YANG data types defined
     by IANA and used for referring to Pseudowire Types.

     Copyright (c) 2021 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Simplified BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (http://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX; see
     the RFC itself for full legal notices.";

  revision 2021-07-05 {
    description
      "First revision.";
    reference
      "RFC XXXX: A Layer 2 VPN Network YANG Model.";
  }

  identity iana-pw-types {
    description
      "Base BGP Layer 2 encapsulation type.";
  }

  identity frame-relay {
    base iana-pw-types;
    description
      "Frame Relay.";
    reference
      "RFC 4619: Encapsulation Methods for Transport of Frame Relay
                 over Multiprotocol Label Switching (MPLS) Networks";
  }

Barguil, et al.         Expires January 29, 2022               [Page 50]
Internet-Draft                    L2NM                         July 2021

  identity atm-aal5 {
    base iana-pw-types;
    description
      "ATM AAL5 SDU VCC transport.";
  }

  identity atm-cell {
    base iana-pw-types;
    description
      "ATM transparent cell transport";
    reference
      "RFC 4717: Encapsulation Methods for Transport of
                 Asynchronous Transfer Mode (ATM) over MPLS
                 Networks";
  }

  identity ethernet-tagged-mode {
    base iana-pw-types;
    description
      "Ethernet (VLAN) Tagged Mode.";
    reference
      "RFC 4448: Encapsulation Methods for Transport of Ethernet
                 over MPLS Networks";
  }

  identity ethernet {
    base iana-pw-types;
    description
      "Ethernet.";
    reference
      "RFC 4448: Encapsulation Methods for Transport of Ethernet
                 over MPLS Networks";
  }

  identity hdlc {
    base iana-pw-types;
    description
      "Cisco HDLC.";
    reference
      "RFC 4618: Encapsulation Methods for Transport of
                 PPP/High-Level Data Link Control (HDLC)
                 over MPLS Networks";
  }

  identity ppp {
    base iana-pw-types;
    description
      "PPP.";

Barguil, et al.         Expires January 29, 2022               [Page 51]
Internet-Draft                    L2NM                         July 2021

    reference
      "RFC 4618: Encapsulation Methods for Transport of
                 PPP/High-Level Data Link Control (HDLC)
                 over MPLS Networks";
  }

  identity circuit-emulation-mpls {
    base iana-pw-types;
    description
      "SONET/SDH Circuit Emulation Service Over MPLS Encapsulation.";
    reference
      "RFC 5143: Synchronous Optical Network/Synchronous Digital
                 Hierarchy (SONET/SDH) Circuit Emulation Service over
                 MPLS (CEM) Encapsulation";
  }

  identity atm-to-vcc {
    base iana-pw-types;
    description
      "ATM n-to-one VCC cell transport.";
    reference
      "RFC 4717: Encapsulation Methods for Transport of
                 Asynchronous Transfer Mode (ATM) over MPLS Networks";
  }

  identity atm-to-vpc {
    base iana-pw-types;
    description
      "ATM n-to-one VPC cell transport.";
    reference
      "RFC 4717: Encapsulation Methods for Transport of
                 Asynchronous Transfer Mode (ATM) over MPLS Networks";
  }

  identity layer-2-transport {
    base iana-pw-types;
    description
      "IP Layer2 Transport.";
    reference
      "RFC 3032: MPLS Label Stack Encoding";
  }

  identity atm-one-to-one-vcc {
    base iana-pw-types;
    description
      "ATM one-to-one VCC Cell Mode.";
    reference
      "RFC 4717: Encapsulation Methods for Transport of

Barguil, et al.         Expires January 29, 2022               [Page 52]
Internet-Draft                    L2NM                         July 2021

                 Asynchronous Transfer Mode (ATM) over MPLS Networks";
  }

  identity atm-one-to-one-vpc {
    base iana-pw-types;
    description
      "ATM one-to-one VPC Cell Mode.";
    reference
      "RFC 4717: Encapsulation Methods for Transport of
                 Asynchronous Transfer Mode (ATM) over MPLS Networks";
  }

  identity atm-aal5-vcc {
    base iana-pw-types;
    description
      "ATM AAL5 PDU VCC transport.";
    reference
      "RFC 4717: Encapsulation Methods for Transport of
                 Asynchronous Transfer Mode (ATM) over MPLS Networks";
  }

  identity fr-port-mode {
    base iana-pw-types;
    description
      "Frame-Relay Port mode.";
    reference
      "RFC 4619: Encapsulation Methods for Transport of Frame Relay over
                 Multiprotocol Label Switching (MPLS) Networks";
  }

  identity circuit-emulation-packet {
    base iana-pw-types;
    description
      "SONET/SDH Circuit Emulation over Packet.";
    reference
      "RFC 4842: Synchronous Optical Network/Synchronous Digital
                 Hierarchy (SONET/SDH) Circuit Emulation over Packet
                 (CEP)";
  }

  identity e1 {
    base iana-pw-types;
    description
      "Structure-agnostic E1 over Packet.";
    reference
      "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
                 over Packet (SAToP)";
  }

Barguil, et al.         Expires January 29, 2022               [Page 53]
Internet-Draft                    L2NM                         July 2021

  identity t1 {
    base iana-pw-types;
    description
      "Structure-agnostic T1 (DS1) over Packet.";
    reference
      "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
                 over Packet (SAToP)";
  }

  identity e3 {
    base iana-pw-types;
    description
      "Structure-agnostic E3 over Packet.";
    reference
      "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
                 over Packet (SAToP)";
  }

  identity t3 {
    base iana-pw-types;
    description
      "Structure-agnostic T3 (DS3) over Packet.";
    reference
      "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
                 over Packet (SAToP)";
  }

  identity ces-over-psn {
    base iana-pw-types;
    description
      "CESoPSN basic mode.";
    reference
      "RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
                 Circuit Emulation Service over Packet Switched Network
                 (CESoPSN)";
  }

  identity tdm-over-ip-aal1 {
    base iana-pw-types;
    description
      "TDMoIP AAL1 Mode.";
    reference
      "RFC 5087: Time Division Multiplexing over IP (TDMoIP)";
  }

  identity ces-over-psn-cas {
    base iana-pw-types;
    description

Barguil, et al.         Expires January 29, 2022               [Page 54]
Internet-Draft                    L2NM                         July 2021

      "CESoPSN TDM with CAS.";
    reference
      "RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
                 Circuit Emulation Service over Packet Switched Network
                 (CESoPSN)";
  }

  identity tdm-over-ip-aal2 {
    base iana-pw-types;
    description
      "TDMoIP AAL2 Mode.";
    reference
      "RFC 5087: Time Division Multiplexing over IP (TDMoIP)";
  }

  identity dlci {
    base iana-pw-types;
    description
      "Frame Relay DLCI.";
    reference
      "RFC 4619: Encapsulation Methods for Transport of Frame Relay over
                 Multiprotocol Label Switching (MPLS) Networks";
  }

  identity rohc {
    base iana-pw-types;
    description
      "ROHC Transport Header-compressed Packets.";
    reference
      "RFC 5795: The RObust Header Compression (ROHC) Framework
       RFC 4901: Protocol Extensions for Header Compression over MPLS";
  }

  identity ecrtp {
    base iana-pw-types;
    description
      "ECRTP Transport Header-compressed Packets.";
    reference
      "RFC 3545: Enhanced Compressed RTP (CRTP) for Links with High
                  Delay, Packet Loss and Reordering
       RFC 4901: Protocol Extensions for Header Compression over MPLS";
  }

  identity iphc {
    base iana-pw-types;
    description
      "IPHC Transport Header-compressed Packets.";
    reference

Barguil, et al.         Expires January 29, 2022               [Page 55]
Internet-Draft                    L2NM                         July 2021

      "RFC 2507: IP Header Compression
       RFC 4901: Protocol Extensions for Header Compression over MPLS";
  }

  identity crtp {
    base iana-pw-types;
    description
      "cRTP Transport Header-compressed Packets.";
    reference
      "RFC 2508: Compressing IP/UDP/RTP Headers for Low-Speed Serial
                 Links
       RFC 4901: Protocol Extensions for Header Compression over MPLS";
  }

  identity atm-vp-virtual-trunk {
    base iana-pw-types;
    description
      "ATM VP Virtual Trunk.";
  }

  identity fc-port-mode {
    base iana-pw-types;
    description
      "FC Port Mode.";
    reference
      "RFC 6307: Encapsulation Methods for Transport of
                 Fibre Channel Traffic over MPLS Networks";
  }

  identity wildcard {
    base iana-pw-types;
    description
      "Wildcard.";
    reference
      "RFC 4863: Wildcard Pseudowire Type";
  }
}
<CODE ENDS>

7.3.  L2NM

   The "ietf-l2vpn-ntw" YANG module uses types defined in [RFC6991],
   [I-D.ietf-opsawg-vpn-common], and [RFC8294].

<CODE BEGINS>file "ietf-l2vpn-ntw@2021-07-28.yang"
module ietf-l2vpn-ntw {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw";

Barguil, et al.         Expires January 29, 2022               [Page 56]
Internet-Draft                    L2NM                         July 2021

  prefix l2vpn-ntw;

  import ietf-inet-types {
    prefix inet;
    reference
      "RFC 6991: Common YANG Data Types, Section 4";
  }
  import ietf-yang-types {
    prefix yang;
    reference
      "RFC 6991: Common YANG Data Types, Section 3";
  }
  import ietf-vpn-common {
    prefix vpn-common;
    reference
      "RFC CCCC: A Layer 2/3 VPN Common YANG Model";
  }
  import iana-bgp-l2-encaps {
    prefix iana-bgp-l2-encaps;
  }
  import iana-pseudowire-types {
    prefix iana-pw-types;
  }
  import ietf-routing-types {
    prefix rt-types;
    reference
      "RFC 8294: Common YANG Data Types for the Routing Area";
  }

  organization
    "IETF OPSA (Operations and Management Area) Working Group";
  contact
    "WG Web:   <http://tools.ietf.org/wg/opsawg/>
     WG List:  <mailto:opsawg@ietf.org>

     Editor:    Mohamed Boucadair
               <mailto:mohamed.boucadair@orange.com>
     Editor:    Samier Barguil
               <mailto:samier.barguilgiraldo.ext@telefonica.com>
     Author:    Oscar Gonzalez de Dios
               <mailto:oscar.gonzalezdedios@telefonica.com>";
  description
    "This YANG module defines a network model for layer 2 VPN
     services.

     Copyright (c) 2021 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

Barguil, et al.         Expires January 29, 2022               [Page 57]
Internet-Draft                    L2NM                         July 2021

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Simplified BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (http://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX; see
     the RFC itself for full legal notices.";

  revision 2021-07-28 {
    description
      "Initial version.";
    reference
      "RFC XXXX: A Layer 2 VPN Network YANG Model.";
  }

  /* Features */

  feature oam-3ah {
    description
      "Indicates the support of OAM 802.3ah.";
    reference
      "IEEE Std 802.3ah: Media Access Control Parameters, Physical
                         Layers, and  Management Parameters for
                         Subscriber Access Networks";
  }

  /* Identities */

  identity esi-type {
    description
      "T-(Ethernet Segment Identifier (ESI) Type) is a 1-octet field
       (most significant octet) that specifies the format of the
       remaining 9 octets (ESI Value).";
    reference
      "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 5";
  }

  identity esi-type-0 {
    base esi-type;
    description
      "This type indicates an arbitrary 9-octet ESI value,
       which is managed and configured by the operator.";
  }

  identity esi-type-1 {
    base esi-type;

Barguil, et al.         Expires January 29, 2022               [Page 58]
Internet-Draft                    L2NM                         July 2021

    description
      "When IEEE 802.1AX Link Aggregation Control Protocol (LACP)
       is used between the Provider Edge (PE) and Customer Edge (CE)
       devices, this ESI type indicates an auto-generated ESI value
       determined from LACP.";
  }

  identity esi-type-2 {
    base esi-type;
    description
      "The ESI value is auto-generated and determined based
       on the Layer 2 bridge protocol.";
  }

  identity esi-type-3 {
    base esi-type;
    description
      "This type indicates a MAC-based ESI value that can be
       auto-generated or configured by the operator.";
  }

  identity esi-type-4 {
    base esi-type;
    description
      "This type indicates a Router-ID ESI value that can be
       auto-generated or configured by the operator.";
  }

  identity esi-type-5 {
    base esi-type;
    description
      "This type indicates an Autonomous System (AS)-based ESI value
       that can be auto-generated or configured by the operator.";
  }

  identity df-election-methods {
    description
      "Base Identity Designated Forwarder (DF) election method.";
  }

  identity default-7432 {
    base df-election-methods;
    description
      "The default DF election method.

       The default procedure for DF election at the granularity of <ES,
       VLAN> for VLAN-based service or <ES, VLAN bundle> for VLAN-
       (aware) bundle service is referred to as 'service carving'.";

Barguil, et al.         Expires January 29, 2022               [Page 59]
Internet-Draft                    L2NM                         July 2021

    reference
      "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 8.5";
  }

  identity highest-random-weight {
    base df-election-methods;
    description
      "The highest random weight (HRW) method.";
    reference
      "RFC 8584: Framework for Ethernet VPN Designated
                 Forwarder Election Extensibility, Section 3";
  }

  identity preference {
    base df-election-methods;
    description
      "The preference based method. PEs are assigned with
       preferences to become the DF in the Ethernet Segment (ES).
       The exact preference-based algorithm (e.g., lowest-preference
       algorithm, highest-preference algorithm) to use is
       signaled at the control plane.";
  }

  identity evpn-redundancy-mode {
    description
      "Base identity for Ethernet VPN (EVPN) redundancy modes.";
  }

  identity single-active {
    base evpn-redundancy-mode;
    description
      "Indicates Single-Active redundancy mode for a given ES.";
    reference
      "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 14.1.1";
  }

  identity all-active {
    base evpn-redundancy-mode;
    description
      "Indicates All-Active redundancy mode for a given ES.";
    reference
      "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 14.1.2";
  }

  identity evpn-service-type {
    description
      "Base identity for EVPN service type.";
  }

Barguil, et al.         Expires January 29, 2022               [Page 60]
Internet-Draft                    L2NM                         July 2021

  identity vlan-based-service-interface {
    base evpn-service-type;
    description
      "VLAN-Based Service Interface.";
    reference
      "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.1";
  }

  identity vlan-bundle-service-interface {
    base evpn-service-type;
    description
      "VLAN Bundle Service Interface.";
    reference
      "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.2";
  }

  identity vlan-aware-bundle-service-interface {
    base evpn-service-type;
    description
      "VLAN-Aware Bundle Service Interface.";
    reference
      "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.3";
  }

  identity mapping-type {
    base vpn-common:multicast-gp-address-mapping;
    description
      "Identity for multicast group mapping type.";
  }

  identity loop-prevention-type {
    description
      "Identity of loop prevention.";
  }

  identity shut {
    base loop-prevention-type;
    description
      "Identity of shut protection.";
  }

  identity trap {
    base loop-prevention-type;
    description
      "Identity of trap protection.";
  }

  identity color-type {

Barguil, et al.         Expires January 29, 2022               [Page 61]
Internet-Draft                    L2NM                         July 2021

    description
      "Identity of color types.";
  }

  identity green {
    base color-type;
    description
      "Identity of the 'green' color type.";
  }

  identity yellow {
    base color-type;
    description
      "Identity of the 'yellow' color type.";
  }

  identity red {
    base color-type;
    description
      "Identity of the 'red' color type.";
  }

  identity t-ldp-pw-type {
    description
      "Identity for t-ldp-pw-type.";
  }

  identity vpws-type {
    base t-ldp-pw-type;
    description
      "Identity for VPWS.";
  }

  identity vpls-type {
    base t-ldp-pw-type;
    description
      "Identity for VPLS.";
  }

  identity hvpls {
    base t-ldp-pw-type;
    description
      "Identity for H-VPLS.";
  }

  identity evpn-type {
    description
      "Ethernet VPN types.";

Barguil, et al.         Expires January 29, 2022               [Page 62]
Internet-Draft                    L2NM                         July 2021

  }

  identity evpn-vpws {
    base evpn-type;
    description
      "VPWS support in EVPN.";
  }

  identity evpn-pbb {
    base evpn-type;
    description
      "Provider Backbone Bridging Support in EVPN.";
  }

  identity pm-type {
    description
      "Identity for performance monitoring type.";
  }

  identity loss {
    base pm-type;
    description
      "Loss measurement.";
  }

  identity delay {
    base pm-type;
    description
      "Delay measurement.";
  }

  identity mac-learning-mode {
    description
      "Media Access Control (MAC) learning mode.";
  }

  identity data-plane {
    base mac-learning-mode;
    description
      "User MAC addresses are learned through ARP broadcast.";
  }

  identity control-plane {
    base mac-learning-mode;
    description
      "User MAC addresses are advertised through EVPN-BGP.";
  }

Barguil, et al.         Expires January 29, 2022               [Page 63]
Internet-Draft                    L2NM                         July 2021

  identity mac-action {
    description
      "Base identity for a MAC action.";
  }

  identity drop {
    base mac-action;
    description
      "Identity for dropping a packet.";
  }

  identity flood {
    base mac-action;
    description
      "Identity for packet flooding.";
  }

  identity warning {
    base mac-action;
    description
      "Identity for sending a warning log message.";
  }

  identity precedence-type {
    description
      "Redundancy type. The service can be created
       with active and bakcup signalization.";
  }

  identity primary {
    base precedence-type;
    description
      "Identifies the main VPN network access.";
  }

  identity backup {
    base precedence-type;
    description
      "Identifies the backup VPN network access.";
  }

  identity pw-type {
    description
      "Identity for allowed LDP-based PW type.";
    reference
      "RFC 4762: Virtual Private LAN Service (VPLS) Using
                 Label Distribution Protocol (LDP)
                 Signaling, Section 6.1.1";

Barguil, et al.         Expires January 29, 2022               [Page 64]
Internet-Draft                    L2NM                         July 2021

  }

  identity ethernet {
    base pw-type;
    description
      "Identity for PW Ethernet type.";
  }

  identity ethernet-tagged {
    base pw-type;
    description
      "Identity for PW Ethernet tagged mode type.";
  }

  /* Typedefs */

  typedef ccm-priority-type {
    type uint8 {
      range "0..7";
    }
    description
      "A 3-bit priority value to be used in the VLAN tag,
       if present in the transmitted frame.";
  }

  /* Groupings */

  grouping cfm-802-grouping {
    description
      "Grouping for 802.1ag CFM attributes.";
    reference
      "IEEE Std 802-1ag: Virtual Bridged Local Area Networks
                         Amendment 5: Connectivity Fault Management";
    leaf maid {
      type string;
      description
        "MA ID";
    }
    leaf mep-id {
      type uint32;
      description
        "Local Maintenance End Point (MEP) ID.";
    }
    leaf mep-level {
      type uint32;
      description
        "MEP level.";
    }

Barguil, et al.         Expires January 29, 2022               [Page 65]
Internet-Draft                    L2NM                         July 2021

    leaf mep-up-down {
      type enumeration {
        enum up {
          description
            "MEP is up.";
        }
        enum down {
          description
            "MEP is down.";
        }
      }
      description
        "MEP up/down";
    }
    leaf remote-mep-id {
      type uint32;
      description
        "Remote MEP ID.";
    }
    leaf cos-for-cfm-pdus {
      type uint32;
      description
        "COS for CFM PDUs.";
    }
    leaf ccm-interval {
      type uint32;
      description
        "CCM interval.";
    }
    leaf ccm-holdtime {
      type uint32;
      description
        "CCM hold time.";
    }
    leaf ccm-p-bits-pri {
      type ccm-priority-type;
      description
        "The priority parameter for Continuity Check Messages (CCMs)
         transmitted by the MEP.";
    }
  }

  grouping y-1731 {
    description
      "Grouping for y.1731";
    reference
      "ITU-T Y-1731:  Operations, administration and maintenance
                      (OAM) functions and mechanisms for

Barguil, et al.         Expires January 29, 2022               [Page 66]
Internet-Draft                    L2NM                         July 2021

                      Ethernet-based networks";
    list y-1731 {
      key "maid";
      description
        "List for y-1731.";
      leaf maid {
        type string;
        description
          "MA ID.";
      }
      leaf mep-id {
        type uint32;
        description
          "Local MEP ID.";
      }
      leaf type {
        type identityref {
          base pm-type;
        }
        description
          "Performance monitor types.";
      }
      leaf remote-mep-id {
        type uint32;
        description
          "Remote MEP ID.";
      }
      leaf message-period {
        type uint32;
        description
          "Defines the interval between OAM messages. The message
           period is expressed in milliseconds.";
      }
      leaf measurement-interval {
        type uint32;
        description
          "Specifies the measurement interval for statistics. The
           measurement interval is expressed in seconds.";
      }
      leaf cos {
        type uint32;
        description
          "Identifies the Class of Service.";
      }
      leaf loss-measurement {
        type boolean;
        description
          "Controls whether loss measurement is enabled/disabled.";

Barguil, et al.         Expires January 29, 2022               [Page 67]
Internet-Draft                    L2NM                         July 2021

      }
      leaf synthethic-loss-measurement {
        type boolean;
        description
          "Indicates whether enable synthetic loss measurement.";
      }
      container delay-measurement {
        description
          "Container for delay measurement";
        leaf enable-dm {
          type boolean;
          description
            "Whether to enable delay measurement.";
        }
        leaf two-way {
          type boolean;
          description
            "Whether delay measurement is two-way (true) of one-
             way (false).";
        }
      }
      leaf frame-size {
        type uint32;
        description
          "Frame size";
      }
      leaf session-type {
        type enumeration {
          enum proactive {
            description
              "Proactive mode.";
          }
          enum on-demand {
            description
              "On-demand mode.";
          }
        }
        description
          "Session type.";
      }
    }
  }

  grouping global-parameters-profile {
    description
      "Container for per-service parameters.";
    leaf local-autonomous-system {
      type inet:as-number;

Barguil, et al.         Expires January 29, 2022               [Page 68]
Internet-Draft                    L2NM                         July 2021

      description
        "Indicates a local AS Number (ASN).";
    }
    leaf svc-mtu {
      type uint32;
      description
        "Service MTU, it is also known as the maximum transmission unit
         or maximum frame size. When a frame is larger than the MTU,
         it is fragmented to accommodate the MTU of the network.";
    }
    leaf ce-vlan-preservation {
      type boolean;
      description
        "Preserve the CE-VLAN ID from ingress to egress,i.e.,
         CE-VLAN tag of the egress frame are identical to
         those of the ingress frame that yielded this egress
         service frame. If All-to-One bundling within a site
         is Enabled, then preservation applies to all Ingress
         service frames. If All-to-One bundling is disabled,
         then preservation applies to tagged Ingress service
         frames having CE-VLAN ID 1 through 4094.";
    }
    leaf ce-vlan-cos-perservation {
      type boolean;
      description
        "CE vlan CoS preservation. PCP bits in the CE-VLAN tag
         of the egress frame are identical to those of the ingress
         frame that yielded this egress service frame.";
    }
    leaf control-word-negotiation {
      type boolean;
      description
        "Controls whether Control-word negotiation is enabled
         (if set to true) or not (if set to false).";
      reference
        "Section 7 of RFC 8077";
    }
    container mac-policies {
      description
        "Container of MAC policies.";
      container mac-addr-limit {
        description
          "Container of MAC-Addr limit configuration.";
        leaf mac-num-limit {
          type uint16;
          description
            "Maximum number of MAC addresses learned from
             the customer for a single service instance.";

Barguil, et al.         Expires January 29, 2022               [Page 69]
Internet-Draft                    L2NM                         July 2021

        }
        leaf time-interval {
          type uint32;
          units "milliseconds";
          description
            "The aging time of the mac address.";
        }
        leaf action {
          type identityref {
            base mac-action;
          }
          description
            "Specifies the action when the upper limit is
             exceeded: drop the packet, flood the
             packet, or simply send a warning log message.";
        }
      }
      container mac-loop-prevention {
        description
          "Container for MAC loop prevention.";
        leaf window {
          type uint32;
          units "seconds";
          default "180";
          description
            "The timer when a MAC mobility event is detected.";
        }
        leaf frequency {
          type uint32;
          default "5";
          description
            "The number of times to detect MAC duplication, where
             a 'duplicate MAC address' situation has occurred and
             the duplicate MAC address has been added to a list of
             duplicate MAC addresses.";
        }
        leaf retry-timer {
          type uint32;
          units "seconds";
          description
            "The retry timer. When the retry timer expires,
             the duplicate MAC address will be flushed from
             the MAC-VRF.";
        }
        leaf protection-type {
          type identityref {
            base loop-prevention-type;
          }

Barguil, et al.         Expires January 29, 2022               [Page 70]
Internet-Draft                    L2NM                         July 2021

          description
            "Protection type.";
        }
      }
    }
    container multicast-like {
      if-feature "vpn-common:multicast";
      description
        "Multicast-like container.";
      leaf enabled {
        type boolean;
        default "false";
        description
          "Enables multicast.";
      }
      container customer-tree-flavors {
        description
          "Type of trees used by customer.";
        leaf-list tree-flavor {
          type identityref {
            base vpn-common:multicast-tree-type;
          }
          description
            "Type of multicast tree to be used.";
        }
      }
    }
  }

  /* Main L2NM Container */

  container l2vpn-ntw {
    description
      "Container for the L2NM.";
    container vpn-profiles {
      description
        "Container for VPN profiles.";
      uses vpn-common:vpn-profile-cfg;
    }
    container ethernet-segments {
      description
        "Top container for the Ethernet Segment Identifier (ESI).";
      list ethernet-segment {
        key "name";
        description
          "Top list for ESIs.";
        leaf name {
          type string;

Barguil, et al.         Expires January 29, 2022               [Page 71]
Internet-Draft                    L2NM                         July 2021

          description
            "Includes the name of the Ethernet Segment (ES).";
        }
        leaf esi-type {
          type identityref {
            base esi-type;
          }
          default "esi-type-0";
          description
            "T-(ESI Type) is a 1-octet field (most significant
             octet) that specifies the format of the remaining
             9 octets (ESI Value).";
          reference
            "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 5";
        }
        choice esi-choice {
          description
            "Ethernet segment choice between several types.
             For ESI Type 0: The esi is directly configured by the
                             operator.
             For ESI Type 1: The auto-mode must be used.
             For ESI Type 2: The auto-mode must be used.
             For ESI Type 3: The directly-assigned or auto-mode must
                             be used.
             For ESI Type 4: The directly-assigned or auto-mode must
                             be used.
             For ESI Type 5: The directly-assigned or auto-mode must
                             be used.";
          case directly-assigned {
            description
              "Explicitly assign an ESI value.";
            leaf ethernet-segment-identifier {
              type yang:hex-string {
                length "29";
              }
              description
                "10-octet ESI.";
            }
          }
          case auto-assigned {
            description
              "The ESI is auto-assigned.";
            container esi-auto {
              description
                "The ESI is auto-assigned.";
              choice auto-mode {
                description
                  "Indicates the auto-assignment mode. ESI can be

Barguil, et al.         Expires January 29, 2022               [Page 72]
Internet-Draft                    L2NM                         July 2021

                   automatically assigned either with or without
                   indicating a pool from which the ESI should be
                   taken.

                   For both cases, the server will auto-assign an
                   ESI value 'auto-assigned-ESI' and use that value
                   operationally.";
                case from-pool {
                  leaf esi-pool-name {
                    type string;
                    description
                      "The auto-assignment will be made from the
                       pool identified by the ESI-pool-name.";
                  }
                }
                case full-auto {
                  leaf auto {
                    type empty;
                    description
                      "Indicates an ESI is fully auto-assigned.";
                  }
                }
              }
              leaf auto-ethernet-segment-identifier {
                type yang:hex-string {
                  length "29";
                }
                config false;
                description
                  "The value of the auto-assigned ESI.";
              }
            }
          }
        }
        leaf esi-redundancy-mode {
          type identityref {
            base evpn-redundancy-mode;
          }
          description
            "Indicates the EVPN redundancy mode for a multihomed
             CE.";
          reference
            "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 14.1";
        }
        container df-election {
          description
            "Top container for the DF election method properties.";
          leaf df-election-method {

Barguil, et al.         Expires January 29, 2022               [Page 73]
Internet-Draft                    L2NM                         July 2021

            type identityref {
              base df-election-methods;
            }
            default "default-7432";
            description
              "Specifies the DF election method.";
            reference
              "RFC 8584: Framework for Ethernet VPN Designated
                         Forwarder Election Extensibility";
          }
          leaf preference {
            when "derived-from-or-self(../df-election-method, "
               + "'preference')" {
              description
                "The preference value is only applicable
                 to the preference based method.";
            }
            type uint16;
            description
              "Defines a 2-octet value that indicates the PE
               preference to become the DF in the ES.";
            reference
              "RFC 8584: Framework for Ethernet VPN Designated
                         Forwarder Election Extensibility";
          }
          leaf revertive {
            when "derived-from-or-self(../df-election-method, "
               + "'preference')" {
              description
                "The revertive value is only applicable
                 to the preference method.";
            }
            type boolean;
            default "true";
            description
              "The 'preempt' or 'revertive' behavior. This
               option allows a non-revertive behavior in the
               DF election.";
            reference
              "RFC 8584: Framework for Ethernet VPN Designated
                         Forwarder Election Extensibility";
          }
          leaf election-wait-time {
            type uint32;
            description
              "Election wait timer.";
            reference
              "RFC 8584: Framework for Ethernet VPN Designated

Barguil, et al.         Expires January 29, 2022               [Page 74]
Internet-Draft                    L2NM                         July 2021

                         Forwarder Election Extensibility";
          }
        }
        leaf split-horizon-filtering {
          type boolean;
          description
            "Controls split-horizon filtering.

             In order to achieve split-horizon filtering, every
             Broadcast, unknown unicast, or multicast (BUM)
             packet originating from a non-DF PE is encapsulated
             with an MPLS label that identifies the origin ES.";
          reference
            "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 5";
        }
        container pbb {
          description
            "Provider Backbone Bridging parameters .";
          reference
            "IEEE 802.1ah: Provider Backbone Bridge";
          leaf backbone-src-mac {
            type yang:mac-address;
            description
              "The PEs connected to the same CE must share the
               same Provider Backbone (B-MAC) address in
               All-Active mode.";
            reference
              "RFC 7623: Provider Backbone Bridging Combined with
                         Ethernet VPN (PBB-EVPN), Section 6.2.1.1";
          }
        }
      }
    }
    container vpn-services {
      description
        "Container for L2VPN services.";
      list vpn-service {
        key "vpn-id";
        description
          "Container of a VPN service.";
        uses vpn-common:vpn-description;
        leaf parent-service-id {
          type vpn-common:vpn-id;
          description
            "Pointer to the parent service that
             triggered the L2NM.";
        }
        leaf vpn-type {

Barguil, et al.         Expires January 29, 2022               [Page 75]
Internet-Draft                    L2NM                         July 2021

          type identityref {
            base vpn-common:service-type;
          }
          must "not(derived-from-or-self(current(), "
             + "'vpn-common:l3vpn'))" {
            error-message "L3VPN is only applicable in L3NM.";
          }
          description
            "Service type.";
        }
        leaf vpn-service-topology {
          type identityref {
            base vpn-common:vpn-topology;
          }
          description
            "Defining service topology, such as
             any-to-any, hub-spoke, etc.";
        }
        leaf bgp-ad-enabled {
          type boolean;
          description
            "Indicates whether BGP auto-discovey is enabled
             or disabled.";
        }
        leaf signaling-type {
          type identityref {
            base vpn-common:vpn-signaling-type;
          }
          description
            "VPN signaling type.";
        }
        container global-parameters-profiles {
          description
            "Container for a list of global parameters profiles.";
          list global-parameters-profile {
            key "profile-id";
            description
              "List of global parameters profiles.";
            leaf profile-id {
              type string;
              description
                "The identifier of the global parameters profile.";
            }
            uses vpn-common:route-distinguisher;
            uses vpn-common:vpn-route-targets;
            uses global-parameters-profile;
          }
        }

Barguil, et al.         Expires January 29, 2022               [Page 76]
Internet-Draft                    L2NM                         July 2021

        container underlay-transport {
          description
            "Container for the underlay transport.";
          uses vpn-common:underlay-transport;
        }
        uses vpn-common:service-status;
        container vpn-nodes {
          description
            "Set of VPN nodes that are involved in the L2NM.";
          list vpn-node {
            key "vpn-node-id";
            description
              "Container of the VPN nodes.";
            leaf vpn-node-id {
              type vpn-common:vpn-id;
              description
                "Sets the indentifier of the VPN node.";
            }
            leaf description {
              type string;
              description
                "Textual description of a VPN node.";
            }
            leaf ne-id {
              type string;
              description
                "Indicates the node's IP address.";
            }
            leaf role {
              type identityref {
                base vpn-common:role;
              }
              default "vpn-common:any-to-any-role";
              description
                "Role of the VPN node in the VPN.";
            }
            leaf router-id {
              type rt-types:router-id;
              description
                "A 32-bit number in the dotted-quad format that is
                 used to uniquely identify a node within an
                 autonomous system (AS). ";
            }
            container active-global-parameters-profiles {
              description
                "Container for a list of global parameters profiles.";
              list global-parameters-profile {
                key "profile-id";

Barguil, et al.         Expires January 29, 2022               [Page 77]
Internet-Draft                    L2NM                         July 2021

                description
                  "List of active global parameters profiles.";
                leaf profile-id {
                  type leafref {
                    path "/l2vpn-ntw/vpn-services/vpn-service"
                       + "/global-parameters-profiles"
                       + "/global-parameters-profile/profile-id";
                  }
                  description
                    "Points to a global profile defined at the
                     service level.";
                }
                uses global-parameters-profile;
              }
            }
            uses vpn-common:service-status;
            container bgp-auto-discovery {
              when "/l2vpn-ntw/vpn-services/vpn-service"
                 + "/bgp-ad-enabled = 'true'" {
                description
                  "Only applies when BGP auto-discovery is enabled.";
              }
              description
                "BGP is used for auto-discovery.";
              choice bgp-type {
                description
                  "Choice for the BGP type.";
                case l2vpn-bgp {
                  description
                    "Container for BGP L2VPN.";
                  leaf vpn-id {
                    type vpn-common:vpn-id;
                    description
                      "VPN Identifier. This identifier serves to unify
                       components of a given VPN for the sake of
                       auto-discovery.";
                    reference
                      "RFC 6624: Layer 2 Virtual Private Networks Using
                                 BGP for Auto-Discovery and Signaling";
                  }
                }
                case evpn-bgp {
                  when "derived-from-or-self(/l2vpn-ntw/vpn-services"
                     + "/vpn-service/vpn-type, 'vpn-common:vpws-evpn') "
                     + "or derived-from-or-self(/l2vpn-ntw/vpn-services"
                     + "/vpn-service/vpn-type, 'vpn-common:pbb-evpn') "
                     + "or derived-from-or-self(/l2vpn-ntw/vpn-services"
                     + "/vpn-service/vpn-type, 'vpn-common:mpls-evpn') "

Barguil, et al.         Expires January 29, 2022               [Page 78]
Internet-Draft                    L2NM                         July 2021

                     + "or derived-from-or-self(/l2vpn-ntw/vpn-services"
                     + "/vpn-service/vpn-type, "
                     + "'vpn-common:vxlan-evpn')" {
                    description
                      "Can only be used when EVPN is used.";
                  }
                  description
                    "Container for MP-BGP L2VPN.";
                  leaf evpn-type {
                    type identityref {
                      base evpn-type;
                    }
                    description
                      "EVPN type.";
                  }
                  leaf auto-rt-enable {
                    type boolean;
                    default "false";
                    description
                      "Enables/disabled RT auto-derivation based on
                       the ASN and Ethernet Tag ID.";
                    reference
                      "RFC 7432: BGP MPLS-Based Ethernet VPN,
                                 Section 7.10.1";
                  }
                  leaf auto-route-target {
                    when "../auto-rt-enable = 'true'" {
                      description
                        "Can only be used when auto-RD is enabled.";
                    }
                    type rt-types:route-target;
                    config false;
                    description
                      "The value of the auto-assigned RT.";
                  }
                }
              }
              uses vpn-common:route-distinguisher;
              uses vpn-common:vpn-route-targets;
            }
            container signaling-option {
              description
                "Container for the L2VPN signaling.";
              leaf mtu-pw {
                type uint16;
                description
                  "Sets the PW MTU.";
              }

Barguil, et al.         Expires January 29, 2022               [Page 79]
Internet-Draft                    L2NM                         July 2021

              leaf mtu-allow-mismatch {
                type boolean;
                description
                  "When set to true, it allows MTU mismatch.";
                reference
                  "RFC 4667: Layer 2 Virtual Private Network (L2VPN)
                             Extensions for Layer 2 Tunneling
                             Protocol (L2TP), Section 4.3";
              }
              leaf type {
                type leafref {
                  path "/l2vpn-ntw/vpn-services/vpn-service"
                     + "/signaling-type";
                }
                description
                  "VPN signaling type.";
              }
              choice signaling-option {
                description
                  "Choice for the signaling-option.";
                case bgp {
                  when "derived-from-or-self(./type, "
                     + "'vpn-common:bgp-signaling')" {
                    description
                      "Only applies when VPN signaling type is BGP.";
                  }
                  description
                    "BGP is used as the signaling protocol.";
                  choice bgp-type {
                    description
                      "Choice for the BGP type.";
                    case l2vpn-bgp {
                      description
                        "Container for BGP L2VPN.";
                      leaf ce-id {
                        type uint16;
                        description
                          "The PE must know the set of virtual circuits
                           connecting it to the CE and a CE ID
                           identifying the CE within the VPN.";
                        reference
                          "RFC 6624: Layer 2 Virtual Private Networks
                                     Using BGP for Auto-Discovery and
                                     Signaling";
                      }
                      leaf ce-range {
                        type uint16;
                        description

Barguil, et al.         Expires January 29, 2022               [Page 80]
Internet-Draft                    L2NM                         July 2021

                          "Determines the number of remote CEs with
                           which a given CE can communicate in the
                            contex of a VPN.";
                        reference
                          "RFC 6624: Layer 2 Virtual Private Networks
                                     Using BGP for Auto-Discovery and
                                     Signaling";
                      }
                      leaf pw-encapsulation-type {
                        type identityref {
                          base iana-bgp-l2-encaps:bgp-l2-encaps-type;
                        }
                        description
                          "PW encapsulation type.";
                      }
                      container vpls-instance {
                        when "derived-from-or-self(/l2vpn-ntw"
                           + "/vpn-services/vpn-service/vpn-type, "
                           + "'vpn-common:vpls')" {
                          description
                            "Only applies for VPLS.";
                        }
                        description
                          "VPLS instance.";
                        leaf vpls-edge-id {
                          type uint16;
                          description
                            "VPLS Edge Identifier (VE ID). VE ID";
                          reference
                            "RFC 4761: Virtual Private LAN Service
                                       (VPLS) Using BGP for Auto-
                                       Discovery and Signaling";
                        }
                        leaf vpls-edge-id-range {
                          type uint16;
                          description
                            "Specifies the size of the range of VE ID in
                             a VPLS service. The range controls the size
                             of the label block advertised in the
                             context of a VPLS instance.";
                          reference
                            "RFC 4761: Virtual Private LAN Service
                                       (VPLS) Using BGP for Auto-
                                       Discovery and Signaling";
                        }
                      }
                    }
                    case evpn-bgp {

Barguil, et al.         Expires January 29, 2022               [Page 81]
Internet-Draft                    L2NM                         July 2021

                      description
                        "Container for MP BGP L2VPN.";
                      leaf evpn-type {
                        type leafref {
                          path "/l2vpn-ntw/vpn-services/vpn-service"
                             + "/vpn-nodes/vpn-node/bgp-auto-discovery"
                             + "/evpn-type";
                        }
                        description
                          "EVPN type.";
                      }
                      leaf service-interface-type {
                        type identityref {
                          base evpn-service-type;
                        }
                        description
                          "EVPN service interface type.";
                      }
                      container evpn-policies {
                        description
                          "Includes a set of EVPN policies such as those
                           related to handling MAC addresses.";
                        leaf mac-learning-mode {
                          type identityref {
                            base mac-learning-mode;
                          }
                          description
                            "Indicates through which plane MAC addresses
                             are advertised.";
                        }
                        leaf ingress-replication {
                          type boolean;
                          description
                            "Controles whether ingress replication is
                             enabled/disabled.";
                          reference
                            "RFC 7432: BGP MPLS-Based Ethernet VPN,
                                       Section 8.3.1.1";
                        }
                        leaf p2mp-replication {
                          type boolean;
                          description
                            "Controles whether P2MP replication is
                             enabled/disabled.";
                          reference
                            "RFC 7432: BGP MPLS-Based Ethernet VPN,
                                       Section 8.3.1.2";
                        }

Barguil, et al.         Expires January 29, 2022               [Page 82]
Internet-Draft                    L2NM                         July 2021

                        container arp-proxy {
                          if-feature "vpn-common:ipv4";
                          description
                            "Top container for the ARP Proxy";
                          leaf enable {
                            type boolean;
                            default "false";
                            description
                              "Enables (when set to 'true') or disables
                                (when set to 'false') ARP proxy.";
                          }
                          leaf arp-suppression {
                            type boolean;
                            default "false";
                            description
                              "Enables (when set to 'true') or disables
                               (when set to 'false') ARP suppression.";
                            reference
                              "RFC 7432: BGP MPLS-Based Ethernet VPN";
                          }
                          leaf ip-mobility-threshold {
                            type uint16;
                            description
                              "Enable (TRUE) or disable (FALSE). It is
                               possible for a given host or end-station
                               (as defined by its IP address) to move
                               from one Ethernet segment to another. The
                               number of IP mobility events that
                               are detected for a given IP address
                               within the detection-threshold before it
                               is identified as a duplicate IP address.
                               Once the detection threshold is reached,
                               updates for the IP address are
                               suppressed.";
                          }
                          leaf duplicate-ip-detection-interval {
                            type uint16;
                            description
                              "The time interval used in detecting a
                               duplicate IP address. Duplicate IP
                               address detection number of host moves
                               allowed within interval period";
                          }
                        }
                        container nd-proxy {
                          if-feature "vpn-common:ipv6";
                          description
                            "Top container for the ND Proxy";

Barguil, et al.         Expires January 29, 2022               [Page 83]
Internet-Draft                    L2NM                         July 2021

                          leaf enable {
                            type boolean;
                            default "false";
                            description
                              "Enables (when set to 'true') or disables
                               (when set to 'false') ND proxy. If true
                               the NDP queries for an IP address that
                               is not on that network are suppressed.
                               NDP suppression is a technique that is
                               used to reduce the amount of NDP packets
                               flooding within individual segments,
                               that is between hosts connected to the
                               same logical switch.";
                          }
                          leaf nd-suppression {
                            type boolean;
                            default "false";
                            description
                              "Enables (when set to 'true') or disables
                               (when set to 'false') ND suppression.";
                          }
                          leaf ip-mobility-threshold {
                            type uint16;
                            description
                              "Enable (TRUE) or disable (FALSE). It is
                               possible for a given host or end-station
                               (as defined by its IP address) to move
                               from one ES to another. The number of IP
                               address mobility events that are detected
                               for a  given IP address within the
                               detection-threshold before it is
                               identified as a duplicate IP address.
                               Once the detection threshold is reached,
                               updates for the IP address are
                               suppressed.";
                          }
                          leaf duplicate-ip-detection-interval {
                            type uint16;
                            description
                              "The time interval used in detecting a
                               duplicate IP address. Duplicate IP
                               address detection number of host
                               moves allowed within interval period";
                          }
                        }
                        leaf underlay-multicast {
                          type boolean;
                          default "false";

Barguil, et al.         Expires January 29, 2022               [Page 84]
Internet-Draft                    L2NM                         July 2021

                          description
                            "Enables (when set to 'true') or disables
                             (when set to 'false') underlay multicast.";
                        }
                        leaf flood-unknown-unicast-supression {
                          type boolean;
                          default "false";
                          description
                            "Enables (when set to 'true') or disables
                             (when set to 'false') unknown flood unicast
                             suppression.";
                        }
                        leaf vpws-vlan-aware {
                          type boolean;
                          default "false";
                          description
                            "Enables (when set to 'true') or disables
                             (when set to 'false') VPWS VLAN-aware.";
                        }
                        container bum-management {
                          description
                            "broadcast-unknown-unicast-multicast
                             management";
                          leaf discard-broadcast {
                            type boolean;
                            description
                              "Discards broadcast, when enabled.";
                          }
                          leaf discard-unknown-multicast {
                            type boolean;
                            description
                              "Discards unknown multicast, when
                               enabled.";
                          }
                          leaf discard-unknown-unicast {
                            type boolean;
                            description
                              "Discards unknown unicast, when enabled.";
                          }
                        }
                        container pbb {
                          when "derived-from-or-self(../../evpn-type,"
                             + " 'evpn-pbb')" {
                            description
                              "Only applies for PBB EVPN.";
                          }
                          description
                            "PBB parameters container.";

Barguil, et al.         Expires January 29, 2022               [Page 85]
Internet-Draft                    L2NM                         July 2021

                          reference
                            "IEEE 802.1ah: Provider Backbone Bridge";
                          leaf backbone-src-mac {
                            type yang:mac-address;
                            description
                              "Includes provider backbone MAC (B-MAC)
                               address.";
                            reference
                              "RFC 7623: Provider Backbone Bridging
                                         Combined with Ethernet VPN
                                         (PBB-EVPN), Section 8.1";
                          }
                        }
                      }
                    }
                  }
                }
                container ldp-or-l2tp {
                  description
                    "Container of LDP or L2TP-signaled PWs";
                  leaf agi {
                    type rt-types:route-distinguisher;
                    description
                      "Attachment Group Identifier. Also, called
                       VPLS-Id.";
                    reference
                      "RFC 4667: Layer 2 Virtual Private Network (L2VPN)
                                 Extensions for Layer 2 Tunneling
                                 Protocol (L2TP), Section 4.3
                       RFC 4762: Virtual Private LAN Service (VPLS)
                                 Using Label Distribution Protocol (LDP)
                                 Signaling, Section 6.1.1";
                  }
                  leaf saii {
                    type uint32;
                    description
                      "Source Attachment Individual Identifier.";
                    reference
                      "RFC 4667: Layer 2 Virtual Private Network (L2VPN)
                                 Extensions for Layer 2 Tunneling
                                 Protocol (L2TP), Section 3";
                  }
                  list remote-targets {
                    key "taii";
                    description
                      "List of allowed target AII and peers.";
                    reference
                      "RFC 4667: Layer 2 Virtual Private Network (L2VPN)

Barguil, et al.         Expires January 29, 2022               [Page 86]
Internet-Draft                    L2NM                         July 2021

                                 Extensions for Layer 2 Tunneling
                                 Protocol (L2TP), Section 5";
                    leaf taii {
                      type uint32;
                      description
                        "Target Attachment Individual Identifier.";
                      reference
                        "RFC 4667: Layer 2 Virtual Private Network
                                   (L2VPN) Extensions for Layer 2
                                   Tunneling  Protocol (L2TP),
                                   Section 3";
                    }
                    leaf peer-addr {
                      type inet:ip-address;
                      description
                        "Indicates the peer forwarder's IP address.";
                    }
                  }
                  choice ldp-or-l2tp {
                    description
                      "Choice of LDP or L2TP-signaled PWs";
                    case ldp {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:ldp-signaling')" {
                        description
                          "Only applies when VPN signaling type is Target
                           LDP.";
                      }
                      description
                        "Container of T-LDP PW configurations";
                      leaf t-ldp-pw-type {
                        type identityref {
                          base t-ldp-pw-type;
                        }
                        description
                          "T-LDP PW type.";
                      }
                      leaf pw-type {
                        type identityref {
                          base pw-type;
                        }
                        description
                          "PW encapsulation type.";
                        reference
                          "RFC 4762: Virtual Private LAN Service (VPLS)
                                     Using Label Distribution Protocol (LDP)
                                     Signaling, Section 6.1.1";
                      }

Barguil, et al.         Expires January 29, 2022               [Page 87]
Internet-Draft                    L2NM                         July 2021

                      leaf pw-description {
                        type string;
                        description
                          "Includes an interface description used to send
                           a human-readable administrative string describing
                           the interface to the remote.";
                        reference
                          "RFC 4762: Virtual Private LAN Service (VPLS)
                                     Using Label Distribution Protocol (LDP)
                                     Signaling, Section 6.1.1";
                      }
                      leaf mac-addr-withdraw {
                        type boolean;
                        description
                          "If set to 'true', then MAC address withdrawal
                           is enabled.  If 'false', then MAC address
                           withdrawal is disabled.";
                        reference
                          "RFC 4762: Virtual Private LAN Service (VPLS)
                                     Using Label Distribution Protocol (LDP)
                                     Signaling, Section 6.2";
                      }
                      list ac-pw-list {
                        key "peer-addr vc-id";
                        description
                          "List of AC and PW bindings.";
                        leaf peer-addr {
                          type inet:ip-address;
                          description
                            "Indicates the peer's IP address.";
                        }
                        leaf vc-id {
                          type string;
                          description
                            "VC label used to identify a PW.";
                        }
                        leaf pw-priority {
                          type uint32;
                          description
                            "Defines the priority for the PW.
                             The higher the pw-priority value,
                             the higher the preference of the PW will be.";
                        }
                      }
                      container qinq {
                        when "derived-from-or-self(../t-ldp-pw-type, "
                           + "'hvpls')" {
                          description

Barguil, et al.         Expires January 29, 2022               [Page 88]
Internet-Draft                    L2NM                         July 2021

                            "Only applies when t-ldp pw type is h-vpls.";
                        }
                        description
                          "Container for QinQ.";
                        leaf s-tag {
                          type uint32;
                          description
                            "S-TAG.";
                        }
                        leaf c-tag {
                          type uint32;
                          description
                            "C-TAG.";
                        }
                      }
                    }
                    case l2tp {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:l2tp-signaling')" {
                        description
                          "Applies when VPN signaling type is L2TP.";
                      }
                      description
                        "Container for L2TP PWs.";
                      leaf router-id {
                        type rt-types:router-id;
                        description
                          "A 32-bit number in the dotted-quad format that is
                           used to uniquely identify a node within an
                           autonomous system.";
                        reference
                          "RFC 4667: Layer 2 Virtual Private Network (L2VPN)
                                     Extensions for Layer 2 Tunneling
                                     Protocol (L2TP), Section 4.2";
                      }
                      leaf pseudowire-type {
                        type identityref {
                          base iana-pw-types:iana-pw-types;
                        }
                        description
                          "Encapsulation type.";
                        reference
                          "RFC 4667: Layer 2 Virtual Private Network (L2VPN)
                                     Extensions for Layer 2 Tunneling
                                     Protocol (L2TP), Section 4.2";
                      }
                    }
                  }

Barguil, et al.         Expires January 29, 2022               [Page 89]
Internet-Draft                    L2NM                         July 2021

                }
              }
            }
            container vpn-network-accesses {
              description
                "List of VPN Nodes.";
              list vpn-network-access {
                key "id";
                description
                  "List of VPN Network Accesses.";
                leaf id {
                  type vpn-common:vpn-id;
                  description
                    "Identifier of network access";
                }
                leaf description {
                  type string;
                  description
                    "String to describe the element.";
                }
                leaf interface-id {
                  type string;
                  description
                    "Refers to a physical or logical interface.";
                }
                leaf global-parameters-profile {
                  type leafref {
                    path "/l2vpn-ntw/vpn-services/vpn-service/vpn-nodes"
                       + "/vpn-node/active-global-parameters-profiles"
                       + "/global-parameters-profile/profile-id";
                  }
                  description
                    "An identifier of an active VPN instance profile.";
                }
                uses vpn-common:service-status;
                container connection {
                  description
                    "Container for bearer and AC.";
                  leaf l2-termination-point {
                    type string;
                    description
                      "Specifies a reference to a local layer 2
                       termination point such as a layer 2
                       sub-interface.";
                  }
                  leaf local-bridge-reference {
                    type string;
                    description

Barguil, et al.         Expires January 29, 2022               [Page 90]
Internet-Draft                    L2NM                         July 2021

                      "Specifies a local bridge reference to
                       accommodate, for example, implementations
                       that require internal bridging.
                       A reference may be a local bridge domain.";
                  }
                  leaf bearer-reference {
                    if-feature "vpn-common:bearer-reference";
                    type string;
                    description
                      "This is an internal reference for the service
                       provider to identify the bearer associated
                       with this VPN.";
                  }
                  container encapsulation {
                    description
                      "Container for layer 2 encapsulation.";
                    leaf type {
                      type identityref {
                        base vpn-common:encapsulation-type;
                      }
                      default "vpn-common:priority-tagged";
                      description
                        "Tagged interface type. By default, the type of
                         the tagged interface is 'priority-tagged'.";
                    }
                    container dot1q {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:dot1q')" {
                        description
                          "Only applies when the type of the
                           tagged interface is 'dot1q'.";
                      }
                      if-feature "vpn-common:dot1q";
                      description
                        "Tagged interface.";
                      leaf tag-type {
                        type identityref {
                          base vpn-common:tag-type;
                        }
                        default "vpn-common:c-vlan";
                        description
                          "Tag type. By default, the tag type is
                           'c-vlan'.";
                      }
                      leaf cvlan-id {
                        type uint16;
                        description
                          "VLAN identifier.";

Barguil, et al.         Expires January 29, 2022               [Page 91]
Internet-Draft                    L2NM                         July 2021

                      }
                      container rewrite {
                        description
                          "Sets the tag rewriting policy for this
                           'vpn-network-accesses'. Enables the
                           manipulation of the layer-2 frame header for
                           data frames as they are processed on the
                           'vpn-network-access'.";
                        choice tag-choice {
                          description
                            "Selects the tag rewriting policy for a VPN
                             network access. It defines a set of
                             standard tag manipulations that allow for
                             the insertion, removal, or rewriting of one
                             or two 802.1Q VLAN tags.";
                          leaf pop {
                            type enumeration {
                              enum 1 {
                                description
                                  "Allows one (1) tag removal.";
                              }
                              enum 2 {
                                description
                                  "Allows two (2) tags removal.";
                              }
                            }
                            description
                              "Standard tag removal.
                               The number of 802.1Q VLAN tags to pop.";
                          }
                          leaf push {
                            type empty;
                            description
                              "Standard tag Push.
                               The number of 802.1Q tags to push on the
                               front of the frame.";
                          }
                          leaf translate {
                            type enumeration {
                              enum 1-to-1 {
                                description
                                  "Allows one (1) to one (1) tag
                                   translation.";
                              }
                              enum 1-to-2 {
                                description
                                  "Allows one (1) to two (2) tags
                                   translation.";

Barguil, et al.         Expires January 29, 2022               [Page 92]
Internet-Draft                    L2NM                         July 2021

                              }
                              enum 2-to-1 {
                                description
                                  "Allows two (2) to one (1) tag
                                   translation.";
                              }
                              enum 2-to-2 {
                                description
                                  "Allows two (2) to two (2) tags
                                   translation.";
                              }
                            }
                            description
                              "Replaces tags with other tags.
                               Translate operations are expressed as
                               as a combination of tag push and pop
                               operations. For example, translating the
                               outer tag is expressed as popping a
                               single tag.";
                          }
                        }
                        leaf cvlan-id {
                          when 'not(../pop)';
                          type uint16;
                          description
                            "Push/Translate vlan tags";
                        }
                        leaf direction {
                          type enumeration {
                            enum symmetric {
                              description
                                "TAGs operation is performed in a
                                 symetric way.

                                 The operation is performed on the
                                 outbound traffic on an interface, then
                                 the reverse operation is performed on
                                 the inbound traffic out of the
                                 same interface.";
                            }
                          }
                          description
                            "Indicates the direction.";
                        }
                      }
                    }
                    container priority-tagged {
                      when "derived-from-or-self(../type, "

Barguil, et al.         Expires January 29, 2022               [Page 93]
Internet-Draft                    L2NM                         July 2021

                         + "'vpn-common:priority-tagged')" {
                        description
                          "Only applies when the type of the
                           tagged interface is 'priority-tagged'.";
                      }
                      description
                        "Priority tagged.";
                      leaf tag-type {
                        type identityref {
                          base vpn-common:tag-type;
                        }
                        default "vpn-common:c-vlan";
                        description
                          "Tag type. By default, the tag type is
                           'c-vlan'.";
                      }
                    }
                    container qinq {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:qinq')" {
                        description
                          "Only applies when the type of the tagged
                           interface is QinQ.";
                      }
                      if-feature "vpn-common:qinq";
                      description
                        "Includes QinQ parameters.";
                      leaf tag-type {
                        type identityref {
                          base vpn-common:tag-type;
                        }
                        default "vpn-common:s-c-vlan";
                        description
                          "Tag type. By default, the tag type is
                           's-c-vlan'.";
                      }
                      leaf svlan-id {
                        type uint16;
                        mandatory true;
                        description
                          "S-VLAN identifier.";
                      }
                      leaf cvlan-id {
                        type uint16;
                        mandatory true;
                        description
                          "C-VLAN identifier.";
                      }

Barguil, et al.         Expires January 29, 2022               [Page 94]
Internet-Draft                    L2NM                         July 2021

                    }
                  }
                  container lag-interface {
                    if-feature "vpn-common:lag-interface";
                    description
                      "Container of LAG interface attributes
                       configuration";
                    list lag-interface {
                      key "lag-interface-number";
                      description
                        "List of LAG interfaces";
                      leaf lag-interface-number {
                        type uint32;
                        description
                          "LAG interface number";
                      }
                      container lacp {
                        description
                          "LACP";
                        leaf lacp-state {
                          type boolean;
                          description
                            "LACP on/off";
                        }
                        leaf lacp-mode {
                          type boolean;
                          description
                            "LACP mode";
                        }
                        leaf lacp-speed {
                          type boolean;
                          description
                            "LACP speed";
                        }
                        leaf mini-link {
                          type uint32;
                          description
                            "The minimum aggregate bandwidth for a
                             LAG";
                        }
                        leaf system-id {
                          type yang:mac-address;
                          description
                            "Indicates the System ID used by LACP.";
                        }
                        leaf admin-key {
                          type uint16;
                          description

Barguil, et al.         Expires January 29, 2022               [Page 95]
Internet-Draft                    L2NM                         July 2021

                            "Indicates the value of the key used for the
                             aggregate interface.";
                        }
                        leaf system-priority {
                          type uint16 {
                            range "0..65535";
                          }
                          default "32768";
                          description
                            "Indicates the LACP priority for the
                             system.";
                        }
                        container member-link-list {
                          description
                            "Container of Member link list";
                          list member-link {
                            key "name";
                            description
                              "Member link";
                            leaf name {
                              type string;
                              description
                                "Member link name";
                            }
                            leaf port-speed {
                              type uint32;
                              description
                                "Port speed";
                            }
                            leaf mode {
                              type identityref {
                                base vpn-common:neg-mode;
                              }
                              description
                                "Negotiation mode";
                            }
                            leaf link-mtu {
                              type uint32;
                              description
                                "Link MTU size.";
                            }
                            container oam-802.3ah-link {
                              if-feature "oam-3ah";
                              description
                                "Container for oam 802.3 ah link.";
                              leaf enable {
                                type boolean;
                                description

Barguil, et al.         Expires January 29, 2022               [Page 96]
Internet-Draft                    L2NM                         July 2021

                                  "Indicate whether support OAM 802.3 ah
                                   link.";
                              }
                            }
                          }
                        }
                        leaf flow-control {
                          type string;
                          description
                            "Flow control";
                        }
                        leaf lldp {
                          type boolean;
                          description
                            "LLDP";
                        }
                      }
                    }
                    container split-horizon {
                      description
                        "Configuration with split horizon enabled";
                      leaf group-name {
                        type string;
                        description
                          "group-name of the Split Horizon";
                      }
                    }
                  }
                }
                container vpws-service-instance {
                  when "derived-from-or-self(/l2vpn-ntw/vpn-services"
                     + "/vpn-service/vpn-nodes/vpn-node"
                     + "/bgp-auto-discovery/evpn-type, "
                     + "'evpn-vpws')" {
                    description
                      "Only applies for EVPN-VPWS.";
                  }
                  description
                    "Local and remote VPWS Service Instance (VSI)";
                  reference
                    "RFC 8214: Virtual Private Wire Service Support
                               in Ethernet VPN";
                  choice local-vsi-choice {
                    description
                      "Choices for assigning local VSI.";
                    case directly-assigned {
                      description
                        "Explicitly assign a local VSI.";

Barguil, et al.         Expires January 29, 2022               [Page 97]
Internet-Draft                    L2NM                         July 2021

                      leaf local-vpws-service-instance {
                        type uint32 {
                          range "1..16777215";
                        }
                        description
                          "Indicates the assigned local VSI.";
                      }
                    }
                    case auto-assigned {
                      description
                        "The local VSI is auto-assigned.";
                      container local-vsi-auto {
                        description
                          "The local VSI is auto-assigned.";
                        choice auto-mode {
                          description
                            "Indicates the auto-assignment mode of
                             local VSI. VSI can be automatically
                             assigned either with or without
                             indicating a pool from which the VSI
                             should be taken.

                             For both cases, the server will
                             auto-assign a local VSI value and use
                             that value.";
                          case from-pool {
                            leaf vsi-pool-name {
                              type string;
                              description
                                "The auto-assignment will be made
                                 from this pool.";
                            }
                          }
                          case full-auto {
                            leaf auto {
                              type empty;
                              description
                                "Indicates that a local VSI is
                                 fully auto-assigned.";
                            }
                          }
                        }
                        leaf auto-local-vsi {
                          type uint32 {
                            range "1..16777215";
                          }
                          config false;
                          description

Barguil, et al.         Expires January 29, 2022               [Page 98]
Internet-Draft                    L2NM                         July 2021

                            "The value of the auto-assigned local
                             VSI.";
                        }
                      }
                    }
                  }
                  choice remote-vsi-choice {
                    description
                      "Choice for assigning the remote VSI.";
                    case directly-assigned {
                      description
                        "Explicitly assign a remote VSI.";
                      leaf remote-vpws-service-instance {
                        type uint32 {
                          range "1..16777215";
                        }
                        description
                          "Indicates the value of the remote
                           VSI.";
                      }
                    }
                    case auto-assigned {
                      description
                        "The remote VSI is auto-assigned.";
                      container remote-vsi-auto {
                        description
                          "The remote VSI is auto-assigned.";
                        choice auto-mode {
                          description
                            "Indicates the auto-assignment mode
                             of remote VSI. VSI can be
                             automatically assigned either withor
                             without indicating a pool from which
                             the VSI should be taken.

                             For both cases, the server will
                             auto-assign a remote VSI value and use
                             that value.";
                          case from-pool {
                            leaf vsi-pool-name {
                              type string;
                              description
                                "The auto-assignment will be made
                                 from this pool.";
                            }
                          }
                          case full-auto {
                            leaf auto {

Barguil, et al.         Expires January 29, 2022               [Page 99]
Internet-Draft                    L2NM                         July 2021

                              type empty;
                              description
                                "Indicates that a remote VSI is fully
                                 auto-assigned.";
                            }
                          }
                        }
                        leaf auto-remote-vsi {
                          type uint32 {
                            range "1..16777215";
                          }
                          config false;
                          description
                            "The value of the auto-assigned remote
                             VSI.";
                        }
                      }
                    }
                  }
                }
                list group {
                  key "group-id";
                  description
                    "List of group-ids.";
                  leaf group-id {
                    type string;
                    description
                      "Indicates the group-id to which the network
                       access belongs to.";
                  }
                  leaf group-color {
                    type string;
                    description
                      "Group color associated with a particular VPN.";
                  }
                  leaf precedence {
                    type identityref {
                      base precedence-type;
                    }
                    description
                      "Defining service redundancy in transport
                       network.";
                  }
                  leaf ethernet-segment-identifier {
                    type leafref {
                      path "/l2vpn-ntw/ethernet-segments"
                         + "/ethernet-segment/name";
                    }

Barguil, et al.         Expires January 29, 2022              [Page 100]
Internet-Draft                    L2NM                         July 2021

                    description
                      "Reference to the ESI associated to the VPN
                       network access.";
                  }
                }
                container ethernet-service-oam {
                  description
                    "Container for Ethernet service OAM.";
                  leaf md-name {
                    type string;
                    description
                      "Maintenance domain name.";
                  }
                  leaf md-level {
                    type uint8;
                    description
                      "Maintenance domain level.";
                  }
                  container cfm-802.1-ag {
                    description
                      "Container of 802.1ag CFM configurations.";
                    list n2-uni-c {
                      key "maid";
                      description
                        "List of UNI-N to UNI-C.";
                      uses cfm-802-grouping;
                    }
                    list n2-uni-n {
                      key "maid";
                      description
                        "List of UNI-N to UNI-N.";
                      uses cfm-802-grouping;
                    }
                  }
                  uses y-1731;
                }
                container service {
                  description
                    "Container for service";
                  leaf mtu {
                    type uint32;
                    description
                      "MTU, it is also known as the maximum
                       transmission unit or maximum frame size. When a
                       frame is larger than the MTU, it is broken down,
                       or fragmented, into smaller pieces by the
                       network protocol to accommodate the MTU of the
                       network";

Barguil, et al.         Expires January 29, 2022              [Page 101]
Internet-Draft                    L2NM                         July 2021

                  }
                  container svc-inbound-bandwidth {
                    if-feature "vpn-common:inbound-bw";
                    description
                      "From the PE perspective, the service inbound
                       bandwidth of the connection.";
                    list inbound-bandwidth {
                      key "type";
                      description
                        "List for input bandwidth data nodes.";
                      leaf type {
                        type identityref {
                          base vpn-common:bw-type;
                        }
                        description
                          "Indicates the bandwidth type.";
                      }
                      leaf cos-id {
                        if-feature "vpn-common:qos";
                        type uint8;
                        description
                          "Identifier of the Class of Service (CoS),
                           indicated by DSCP or a CE-CLAN
                           CoS (802.1p) value in the service frame.";
                      }
                      leaf cir {
                        type uint64;
                        description
                          "Committed Information Rate. The maximum
                           number of bits that a port can receive or
                           send during one-second over an interface.";
                      }
                      leaf cbs {
                        type uint64;
                        description
                          "Committed Burst Size. CBS controls the bursty
                           nature of the traffic. Traffic that does not
                           use the configured CIR accumulates credits
                           until the credits reach the configured CBS.";
                      }
                      leaf eir {
                        type uint64;
                        description
                          "Excess Information Rate, i.e., excess frame
                           delivery allowed not subject to SLA. The
                           traffic rate can be limited by EIR.";
                      }
                      leaf ebs {

Barguil, et al.         Expires January 29, 2022              [Page 102]
Internet-Draft                    L2NM                         July 2021

                        type uint64;
                        description
                          "Excess Burst Size. The bandwidth available
                           for burst traffic from the EBS is subject to
                           the amount of bandwidth that is accumulated
                           during periods when traffic allocated by the
                           EIR policy is not used.";
                      }
                      leaf pir {
                        type uint64;
                        description
                          "Peak Information Rate, i.e., maixmum frame
                           delivery allowed. It is equal to or less
                           than sum of CIR and EIR.";
                      }
                      leaf pbs {
                        type uint64;
                        units "bytes per second";
                        description
                          "Peak Burst Size.";
                      }
                    }
                  }
                  container svc-outbound-bandwidth {
                    if-feature "vpn-common:outbound-bw";
                    description
                      "From the PE perspective, the service outbound
                       bandwidth of the connection.";
                    list outbound-bandwidth {
                      key "type";
                      description
                        "List for outbound bandwidth";
                      leaf type {
                        type identityref {
                          base vpn-common:bw-type;
                        }
                        description
                          "Bandwidth Type";
                      }
                      leaf cos-id {
                        if-feature "vpn-common:qos";
                        type uint8;
                        description
                          "Identifier of the CoS, indicated by
                           DSCP or a CE-CLAN CoS (802.1p) value in
                           the service frame.";
                      }
                      leaf cir {

Barguil, et al.         Expires January 29, 2022              [Page 103]
Internet-Draft                    L2NM                         July 2021

                        type uint64;
                        description
                          "Committed Information Rate. The maximum
                           number of bits that a port can receive or
                           send during one-second over an interface.";
                      }
                      leaf cbs {
                        type uint64;
                        description
                          "Committed Burst Size. CBS controls the bursty
                           nature of the traffic. Traffic that does not
                           use the configured CIR accumulates credits
                           until the credits reach the configured CBS.";
                      }
                      leaf eir {
                        type uint64;
                        description
                          "Excess Information Rate, i.e., excess frame
                           delivery allowed not subject to SLA. The
                           traffic rate can be limited by EIR.";
                      }
                      leaf ebs {
                        type uint64;
                        description
                          "Excess Burst Size. The bandwidth available
                           for burst traffic from the EBS is subject to
                           the amount of bandwidth that is accumulated
                           during periods when traffic allocated by the
                           EIR policy is not used.";
                      }
                      leaf pir {
                        type uint64;
                        description
                          "Peak Information Rate, i.e., maixmum frame
                           delivery allowed. It is equal to or less than
                           sum of CIR and EIR.";
                      }
                      leaf pbs {
                        type uint64;
                        units "bytes per second";
                        description
                          "Peak Burst Size.";
                      }
                    }
                  }
                  container qos {
                    if-feature "vpn-common:qos";
                    description

Barguil, et al.         Expires January 29, 2022              [Page 104]
Internet-Draft                    L2NM                         July 2021

                      "QoS configuration.";
                    container qos-classification-policy {
                      description
                        "Configuration of the traffic classification
                         policy.";
                      list rule {
                        key "id";
                        ordered-by user;
                        description
                          "List of classification rules.";
                        leaf id {
                          type string;
                          description
                            "A description identifying the QoS
                             classification policy rule.";
                        }
                        choice match-type {
                          default "match-flow";
                          description
                            "Choice for classification.";
                          case match-flow {
                            container match-flow {
                              description
                                "Describes flow-matching criteria.";
                              leaf dscp {
                                type inet:dscp;
                                description
                                  "DSCP value.";
                              }
                              leaf dot1q {
                                type uint16;
                                description
                                  "802.1Q matching. It is a VLAN tag
                                   added into a frame.";
                              }
                              leaf pcp {
                                type uint8 {
                                  range "0..7";
                                }
                                description
                                  "PCP value.";
                              }
                              leaf src-mac-address {
                                type yang:mac-address;
                                description
                                  "Source MAC address.";
                              }
                              leaf dst-mac-address {

Barguil, et al.         Expires January 29, 2022              [Page 105]
Internet-Draft                    L2NM                         July 2021

                                type yang:mac-address;
                                description
                                  "Destination MAC address.";
                              }
                              leaf color-type {
                                type identityref {
                                  base color-type;
                                }
                                description
                                  "Color type.";
                              }
                              leaf any {
                                type empty;
                                description
                                  "Allows all.";
                              }
                            }
                          }
                          case match-application {
                            leaf match-application {
                              type identityref {
                                base vpn-common:customer-application;
                              }
                              description
                                "Defines the application to match.";
                            }
                          }
                        }
                        leaf target-class-id {
                          type string;
                          description
                            "Identification of the CoS.
                             This identifier is internal to the
                             administration.";
                        }
                      }
                    }
                    container qos-profile {
                      description
                        "QoS profile configuration.";
                      list qos-profile {
                        key "profile";
                        description
                          "QoS profile.
                           Can be standard profile or customized
                           profile.";
                        leaf profile {
                          type leafref {

Barguil, et al.         Expires January 29, 2022              [Page 106]
Internet-Draft                    L2NM                         July 2021

                            path "/l2vpn-ntw/vpn-profiles"
                               + "/valid-provider-identifiers"
                               + "/qos-profile-identifier/id";
                          }
                          description
                            "QoS profile to be used.";
                        }
                        leaf direction {
                          type identityref {
                            base vpn-common:qos-profile-direction;
                          }
                          default "vpn-common:both";
                          description
                            "The direction to which the QoS profile
                             is applied.";
                        }
                      }
                    }
                  }
                  container mac-policies {
                    description
                      "Container for MAC-related policies.";
                    list access-control-list {
                      key "name";
                      description
                        "Container for access control List.";
                      leaf name {
                        type string;
                        description
                          "Specifies the name of the ACL.";
                      }
                      leaf-list src-mac-address {
                        type yang:mac-address;
                        description
                          "Specifies the source MAC address.";
                      }
                      leaf-list src-mac-address-mask {
                        type yang:mac-address;
                        description
                          "Specifies the source MAC address mask.";
                      }
                      leaf-list dst-mac-address {
                        type yang:mac-address;
                        description
                          "Specifies the destination MAC address.";
                      }
                      leaf-list dst-mac-address-mask {
                        type yang:mac-address;

Barguil, et al.         Expires January 29, 2022              [Page 107]
Internet-Draft                    L2NM                         July 2021

                        description
                          "Specifies the destination MAC address mask.";
                      }
                      leaf action {
                        type identityref {
                          base mac-action;
                        }
                        default "drop";
                        description
                          "Specifies the filtering action.";
                      }
                      leaf rate-limit {
                        when "derived-from-or-self(../action, 'flood')" {
                          description
                            "Rate-limit is valid only when the action is
                             to accept the matching frame.";
                        }
                        type decimal64 {
                          fraction-digits 2;
                        }
                        units "bytes per second";
                        description
                          "Specifies how to rate-limit the traffic.";
                      }
                    }
                    container mac-loop-prevention {
                      description
                        "Container of MAC loop prevention.";
                      leaf window {
                        type uint32;
                        units "seconds";
                        default "180";
                        description
                          "The timer when a MAC mobility event is
                           detected.";
                      }
                      leaf frequency {
                        type uint32;
                        default "5";
                        description
                          "The number of times to detect MAC
                           duplication, where a 'duplicate MAC address'
                           situation has occurred and the duplicate MAC
                           address has been added to a list of duplicate
                           MAC addresses.";
                      }
                      leaf retry-timer {
                        type uint32;

Barguil, et al.         Expires January 29, 2022              [Page 108]
Internet-Draft                    L2NM                         July 2021

                        units "seconds";
                        description
                          "The retry timer. When the retry timer
                           expires, the duplicate MAC address will be
                           flushed from the MAC-VRF.";
                      }
                      leaf protection-type {
                        type identityref {
                          base loop-prevention-type;
                        }
                        description
                          "Protection type";
                      }
                    }
                    container mac-addr-limit {
                      description
                        "Container of MAC-Addr limit configurations";
                      leaf mac-num-limit {
                        type uint16;
                        description
                          "maximum number of MAC addresses learned from
                           the subscriber for a single service
                           instance.";
                      }
                      leaf time-interval {
                        type uint32;
                        units "milliseconds";
                        description
                          "The aging time of the mac address.";
                      }
                      leaf action {
                        type identityref {
                          base mac-action;
                        }
                        description
                          "specify the action when the upper limit is
                           exceeded: drop the packet, flood the
                           packet, or simply send a warning log
                           message.";
                      }
                    }
                  }
                  container broadcast-unknown-unicast-multicast {
                    description
                      "Container of broadcast, unknown unicast, and
                       multicast configurations";
                    leaf multicast-site-type {
                      type enumeration {

Barguil, et al.         Expires January 29, 2022              [Page 109]
Internet-Draft                    L2NM                         July 2021

                        enum receiver-only {
                          description
                            "The site only has receivers.";
                        }
                        enum source-only {
                          description
                            "The site only has sources.";
                        }
                        enum source-receiver {
                          description
                            "The site has both sources and receivers.";
                        }
                      }
                      default "source-receiver";
                      description
                        "Type of multicast site.";
                    }
                    list multicast-gp-address-mapping {
                      key "id";
                      description
                        "List of Port to group mappings.";
                      leaf id {
                        type uint16;
                        description
                          "Unique identifier for the mapping.";
                      }
                      leaf vlan-id {
                        type uint32;
                        description
                          "The VLAN ID of the Multicast group.";
                      }
                      leaf mac-gp-address {
                        type yang:mac-address;
                        description
                          "The MAC address of the Multicast group.";
                      }
                      leaf port-lag-number {
                        type uint32;
                        description
                          "The ports/LAGs belonging to the Multicast
                           group.";
                      }
                    }
                    leaf bum-overall-rate {
                      type uint32;
                      description
                        "overall rate for BUM.";
                    }

Barguil, et al.         Expires January 29, 2022              [Page 110]
Internet-Draft                    L2NM                         July 2021

                  }
                }
              }
            }
          }
        }
      }
    }
  }
}
<CODE ENDS>

8.  Security Considerations

   The YANG modules specified in this document defines schema for data
   that is designed to be accessed via network management protocols such
   as NETCONF [RFC6241] or RESTCONF [RFC8040] . The lowest NETCONF layer
   is the secure transport layer, and the mandatory-to-implement secure
   transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
   is HTTPS, and the mandatory-to-implement secure transport is TLS
   [RFC8446].

   The Network Configuration Access Control Model (NACM) [RFC8341]
   provides the means to restrict access for particular NETCONF or
   RESTCONF users to a preconfigured subset of all available NETCONF or
   RESTCONF protocol operations and content.

   There are a number of data nodes defined in "ietf-l2vpn-ntw" YANG
   module that are writable/creatable/deletable (i.e., config true,
   which is the default).  These data nodes may be considered sensitive
   or vulnerable in some network environments.  Write operations (e.g.,
   edit-config) and delete operations to these data nodes without proper
   protection or authentication can have a negative effect on network
   operations.  These are the subtrees and data nodes and their
   sensitivity/vulnerability in the "ietf-l2vpn-ntw" module:

   o  'vpn-service': An attacker who is able to access network nodes can
      undertake various attacks, such as deleting a running L2VPN
      service, interrupting all the traffic of a client.  In addition,
      an attacker may modify the attributes of a running service (e.g.,
      QoS, bandwidth), leading to malfunctioning of the service and
      therefore to SLA violations.  In addition, an attacker could
      attempt to create an L2VPN service or adding a new network access.
      Such activity can be detected by adequately monitoring and
      tracking network configuration changes.

   Some of the readable data nodes in the "ietf-l2vpn-ntw" YANG module
   may be considered sensitive or vulnerable in some network

Barguil, et al.         Expires January 29, 2022              [Page 111]
Internet-Draft                    L2NM                         July 2021

   environments.  It is thus important to control read access (e.g., via
   get, get-config, or notification) to these data nodes.  These are the
   subtrees and data nodes and their sensitivity/vulnerability:

   o  'customer-name' and 'ip-connection': An attacker can retrieve
      privacy-related information which can be used to track a customer.
      Disclosing such information may be considered as a violation of
      the customer-provider trust relationship.

   The following summarizes the foreseen risks of using the "ietf-l2vpn-
   ntw" module can be classified into:

   o  Malicious clients attempting to delete or modify VPN services.

   o  Unauthorized clients attempting to create/modify/delete a VPN
      service.

   o  Unauthorized clients attempting to read VPN service related
      information.

   Both "iana-bgp-l2-encaps" and "iana-pseudowire-types" modules define
   YANG identities for encapsulation/pseudowires types.  These
   identities are intended to be referenced by other YANG modules, and
   by themselves do not expose any nodes which are writable, contain
   read-only state, or RPCs.

9.  IANA Considerations

9.1.  YANG Modules

   This document requests IANA to register the following URIs in the
   "ns" subregistry within the "IETF XML Registry" [RFC3688]:

         URI: urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps
         Registrant Contact: The IESG.
         XML: N/A; the requested URI is an XML namespace.

         URI: urn:ietf:params:xml:ns:yang:iana-pseudowire-types
         Registrant Contact: The IESG.
         XML: N/A; the requested URI is an XML namespace.

         URI: urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw
         Registrant Contact: The IESG.
         XML: N/A; the requested URI is an XML namespace.

   This document requests IANA to register the following YANG modules in
   the "YANG Module Names" subregistry [RFC6020] within the "YANG
   Parameters" registry:

Barguil, et al.         Expires January 29, 2022              [Page 112]
Internet-Draft                    L2NM                         July 2021

         name: iana-bgp-l2-encaps
         namespace: urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps
         maintained by IANA: Y
         prefix: iana-bgp-l2-encaps
         reference: RFC XXXX

         name: iana-pseudowire-types
         namespace: urn:ietf:params:xml:ns:yang:iana-pseudowire-types
         maintained by IANA: Y
         prefix: iana-pw-types
         reference: RFC XXXX

         name: ietf-l2vpn-ntw
         namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw
         maintained by IANA: N
         prefix: l2vpn-ntw
         reference: RFC XXXX

9.2.  BGP Layer 2 Encapsulation Types

   This document defines the initial version of the IANA-maintained
   "iana-bgp-l2-encaps" YANG module.  IANA is requested to add this note
   for both modules:

      BGP Layer 2 encapsulation types must not be directly added to the
      "iana-bgp-l2-encaps" YANG module.  They must instead be
      respectively added to the "BGP Layer 2 Encapsulation Types"
      registry [IANA-BGP-L2].

   When a Layer 2 encapsulation type is added to the "BGP Layer 2
   Encapsulation Types" registry, a new "identity" statement must be
   added to the "iana-bgp-l2-encaps" YANG module.  The name of the
   "identity" is the lower-case of encapsulation name provided in the
   description.  The "identity" statement should have the following sub-
   statements defined:

   "base":        Contains 'bgp-l2-encaps-type'.

   "description": Replicates the description from the registry.

   "reference":   Replicates the reference from the registry and add the
                  title of the document.

   Unassigned or reserved values are not present in the module.

   When the "iana-bgp-l2-encaps" YANG module is updated, a new
   "revision" statement must be added in front of the existing revision
   statements.

Barguil, et al.         Expires January 29, 2022              [Page 113]
Internet-Draft                    L2NM                         July 2021

   IANA is requested to add this note to [IANA-BGP-L2]:

      When this registry is modified, the YANG module "iana-bgp-
      l2-encaps" must be updated as defined in RFCXXXX.

9.3.  Pseudowire Types

   This document defines the initial version of the IANA-maintained
   "iana-pseudowire-types" YANG module.  IANA is requested to add this
   note for both modules:

      MPLS pseudowire types must not be directly added to the "iana-bgp-
      l2-encaps" YANG module.  They must instead be respectively added
      to the "MPLS Pseudowire Types" registry [IANA-PW-Types].

   When a pseudowire type is added to the "iana-pseudowire-types"
   registry, a new "identity" statement must be added to the "iana-
   pseudowire-types" YANG module.  The name of the "identity" is the
   lower-case of encapsulation name provided in the description.  The
   "identity" statement should have the following sub-statements
   defined:

   "base":        Contains 'iana-pw-types'.

   "description": Replicates the description from the registry.

   "reference":   Replicates the reference from the registry and add the
                  title of the document.

   Unassigned or reserved values are not present in the module.

   When the "iana-pseudowire-types" YANG module is updated, a new
   "revision" statement must be added in front of the existing revision
   statements.

   IANA is requested to add this note to [IANA-PW-Types]:

      When this registry is modified, the YANG module "iana-pseudowire-
      types" must be updated as defined in RFCXXXX.

10.  References

10.1.  Normative References

   [I-D.ietf-opsawg-vpn-common]
              Barguil, S., Dios, O. G. D., Boucadair, M., and Q. Wu, "A
              Layer 2/3 VPN Common YANG Model", draft-ietf-opsawg-vpn-
              common-09 (work in progress), July 2021.

Barguil, et al.         Expires January 29, 2022              [Page 114]
Internet-Draft                    L2NM                         July 2021

   [IANA-BGP-L2]
              Internet Assigned Numbers Authority, "BGP Layer 2
              Encapsulation Types", <https://www.iana.org/assignments/
              bgp-parameters/bgp-parameters.xhtml#bgp-l2-encapsulation-
              types-registry>.

   [IANA-PW-Types]
              IANA, "MPLS Pseudowire Types Registry",
              <http://www.iana.org/assignments/pwe3-parameters/
              pwe3-parameters.xhtml#pwe3-parameters-2>.

   [IEEE-802-1ag]
              IEEE, "802.1ag - 2007 - IEEE Standard for Local and
              Metropolitan Area Networks - Virtual Bridged Local Area
              Networks Amendment 5: Connectivity Fault Management",
              2007, <DOI 10.1109/IEEESTD.2007.4431836>.

   [ITU-T-Y-1731]
              Union, I. T., "Operations, administration and maintenance
              (OAM) functions and mechanisms for Ethernet-based
              networks", August 2015,
              <https://www.itu.int/rec/T-REC-Y.1731/en>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC4667]  Luo, W., "Layer 2 Virtual Private Network (L2VPN)
              Extensions for Layer 2 Tunneling Protocol (L2TP)",
              RFC 4667, DOI 10.17487/RFC4667, September 2006,
              <https://www.rfc-editor.org/info/rfc4667>.

   [RFC4761]  Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
              LAN Service (VPLS) Using BGP for Auto-Discovery and
              Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
              <https://www.rfc-editor.org/info/rfc4761>.

   [RFC4762]  Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
              LAN Service (VPLS) Using Label Distribution Protocol (LDP)
              Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
              <https://www.rfc-editor.org/info/rfc4762>.

Barguil, et al.         Expires January 29, 2022              [Page 115]
Internet-Draft                    L2NM                         July 2021

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [RFC6074]  Rosen, E., Davie, B., Radoaca, V., and W. Luo,
              "Provisioning, Auto-Discovery, and Signaling in Layer 2
              Virtual Private Networks (L2VPNs)", RFC 6074,
              DOI 10.17487/RFC6074, January 2011,
              <https://www.rfc-editor.org/info/rfc6074>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              <https://www.rfc-editor.org/info/rfc6242>.

   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
              RFC 6991, DOI 10.17487/RFC6991, July 2013,
              <https://www.rfc-editor.org/info/rfc6991>.

   [RFC7432]  Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
              Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
              Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
              2015, <https://www.rfc-editor.org/info/rfc7432>.

   [RFC7623]  Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
              Henderickx, "Provider Backbone Bridging Combined with
              Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
              September 2015, <https://www.rfc-editor.org/info/rfc7623>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8077]  Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and
              Maintenance Using the Label Distribution Protocol (LDP)",
              STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017,
              <https://www.rfc-editor.org/info/rfc8077>.

Barguil, et al.         Expires January 29, 2022              [Page 116]
Internet-Draft                    L2NM                         July 2021

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8214]  Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
              Rabadan, "Virtual Private Wire Service Support in Ethernet
              VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
              <https://www.rfc-editor.org/info/rfc8214>.

   [RFC8294]  Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
              "Common YANG Data Types for the Routing Area", RFC 8294,
              DOI 10.17487/RFC8294, December 2017,
              <https://www.rfc-editor.org/info/rfc8294>.

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [RFC8342]  Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
              and R. Wilton, "Network Management Datastore Architecture
              (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
              <https://www.rfc-editor.org/info/rfc8342>.

   [RFC8365]  Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
              Uttaro, J., and W. Henderickx, "A Network Virtualization
              Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
              DOI 10.17487/RFC8365, March 2018,
              <https://www.rfc-editor.org/info/rfc8365>.

   [RFC8466]  Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG
              Data Model for Layer 2 Virtual Private Network (L2VPN)
              Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October
              2018, <https://www.rfc-editor.org/info/rfc8466>.

10.2.  Informative References

   [I-D.ietf-bess-evpn-pref-df]
              Rabadan, J., Sathappan, S., Przygienda, T., Lin, W.,
              Drake, J., Sajassi, A., and S. Mohanty, "Preference-based
              EVPN DF Election", draft-ietf-bess-evpn-pref-df-07 (work
              in progress), March 2021.

   [I-D.ietf-idr-bgp-model]
              Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP
              YANG Model for Service Provider Networks", draft-ietf-idr-
              bgp-model-11 (work in progress), July 2021.

Barguil, et al.         Expires January 29, 2022              [Page 117]
Internet-Draft                    L2NM                         July 2021

   [I-D.ietf-teas-enhanced-vpn]
              Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
              Framework for Enhanced Virtual Private Network (VPN+)
              Services", draft-ietf-teas-enhanced-vpn-08 (work in
              progress), July 2021.

   [I-D.ietf-teas-ietf-network-slices]
              Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S.,
              Makhijani, K., Contreras, L. M., and J. Tantsura,
              "Framework for IETF Network Slices", draft-ietf-teas-ietf-
              network-slices-03 (work in progress), May 2021.

   [IEEE802.1AX]
              "Link Aggregation", IEEE Std 802.1AX-2020, 2020.

   [PYANG]    "pyang", November 2020,
              <https://github.com/mbj4668/pyang>.

   [RFC2507]  Degermark, M., Nordgren, B., and S. Pink, "IP Header
              Compression", RFC 2507, DOI 10.17487/RFC2507, February
              1999, <https://www.rfc-editor.org/info/rfc2507>.

   [RFC2508]  Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
              Headers for Low-Speed Serial Links", RFC 2508,
              DOI 10.17487/RFC2508, February 1999,
              <https://www.rfc-editor.org/info/rfc2508>.

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
              <https://www.rfc-editor.org/info/rfc3032>.

   [RFC3545]  Koren, T., Casner, S., Geevarghese, J., Thompson, B., and
              P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with
              High Delay, Packet Loss and Reordering", RFC 3545,
              DOI 10.17487/RFC3545, July 2003,
              <https://www.rfc-editor.org/info/rfc3545>.

   [RFC3644]  Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B.
              Moore, "Policy Quality of Service (QoS) Information
              Model", RFC 3644, DOI 10.17487/RFC3644, November 2003,
              <https://www.rfc-editor.org/info/rfc3644>.

   [RFC4446]  Martini, L., "IANA Allocations for Pseudowire Edge to Edge
              Emulation (PWE3)", BCP 116, RFC 4446,
              DOI 10.17487/RFC4446, April 2006,
              <https://www.rfc-editor.org/info/rfc4446>.

Barguil, et al.         Expires January 29, 2022              [Page 118]
Internet-Draft                    L2NM                         July 2021

   [RFC4448]  Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
              "Encapsulation Methods for Transport of Ethernet over MPLS
              Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
              <https://www.rfc-editor.org/info/rfc4448>.

   [RFC4553]  Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure-
              Agnostic Time Division Multiplexing (TDM) over Packet
              (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006,
              <https://www.rfc-editor.org/info/rfc4553>.

   [RFC4618]  Martini, L., Rosen, E., Heron, G., and A. Malis,
              "Encapsulation Methods for Transport of PPP/High-Level
              Data Link Control (HDLC) over MPLS Networks", RFC 4618,
              DOI 10.17487/RFC4618, September 2006,
              <https://www.rfc-editor.org/info/rfc4618>.

   [RFC4619]  Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed.,
              "Encapsulation Methods for Transport of Frame Relay over
              Multiprotocol Label Switching (MPLS) Networks", RFC 4619,
              DOI 10.17487/RFC4619, September 2006,
              <https://www.rfc-editor.org/info/rfc4619>.

   [RFC4664]  Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
              2 Virtual Private Networks (L2VPNs)", RFC 4664,
              DOI 10.17487/RFC4664, September 2006,
              <https://www.rfc-editor.org/info/rfc4664>.

   [RFC4717]  Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N.,
              Brayley, J., and G. Koleyni, "Encapsulation Methods for
              Transport of Asynchronous Transfer Mode (ATM) over MPLS
              Networks", RFC 4717, DOI 10.17487/RFC4717, December 2006,
              <https://www.rfc-editor.org/info/rfc4717>.

   [RFC4816]  Malis, A., Martini, L., Brayley, J., and T. Walsh,
              "Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous
              Transfer Mode (ATM) Transparent Cell Transport Service",
              RFC 4816, DOI 10.17487/RFC4816, February 2007,
              <https://www.rfc-editor.org/info/rfc4816>.

   [RFC4842]  Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig,
              "Synchronous Optical Network/Synchronous Digital Hierarchy
              (SONET/SDH) Circuit Emulation over Packet (CEP)",
              RFC 4842, DOI 10.17487/RFC4842, April 2007,
              <https://www.rfc-editor.org/info/rfc4842>.

   [RFC4863]  Martini, L. and G. Swallow, "Wildcard Pseudowire Type",
              RFC 4863, DOI 10.17487/RFC4863, May 2007,
              <https://www.rfc-editor.org/info/rfc4863>.

Barguil, et al.         Expires January 29, 2022              [Page 119]
Internet-Draft                    L2NM                         July 2021

   [RFC4901]  Ash, J., Ed., Hand, J., Ed., and A. Malis, Ed., "Protocol
              Extensions for Header Compression over MPLS", RFC 4901,
              DOI 10.17487/RFC4901, June 2007,
              <https://www.rfc-editor.org/info/rfc4901>.

   [RFC5086]  Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and
              P. Pate, "Structure-Aware Time Division Multiplexed (TDM)
              Circuit Emulation Service over Packet Switched Network
              (CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007,
              <https://www.rfc-editor.org/info/rfc5086>.

   [RFC5087]  Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi,
              "Time Division Multiplexing over IP (TDMoIP)", RFC 5087,
              DOI 10.17487/RFC5087, December 2007,
              <https://www.rfc-editor.org/info/rfc5087>.

   [RFC5143]  Malis, A., Brayley, J., Shirron, J., Martini, L., and S.
              Vogelsang, "Synchronous Optical Network/Synchronous
              Digital Hierarchy (SONET/SDH) Circuit Emulation Service
              over MPLS (CEM) Encapsulation", RFC 5143,
              DOI 10.17487/RFC5143, February 2008,
              <https://www.rfc-editor.org/info/rfc5143>.

   [RFC5795]  Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
              Header Compression (ROHC) Framework", RFC 5795,
              DOI 10.17487/RFC5795, March 2010,
              <https://www.rfc-editor.org/info/rfc5795>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <https://www.rfc-editor.org/info/rfc5880>.

   [RFC6307]  Black, D., Ed., Dunbar, L., Ed., Roth, M., and R. Solomon,
              "Encapsulation Methods for Transport of Fibre Channel
              Traffic over MPLS Networks", RFC 6307,
              DOI 10.17487/RFC6307, April 2012,
              <https://www.rfc-editor.org/info/rfc6307>.

   [RFC6624]  Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2
              Virtual Private Networks Using BGP for Auto-Discovery and
              Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012,
              <https://www.rfc-editor.org/info/rfc6624>.

   [RFC7209]  Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N.,
              Henderickx, W., and A. Isaac, "Requirements for Ethernet
              VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014,
              <https://www.rfc-editor.org/info/rfc7209>.

Barguil, et al.         Expires January 29, 2022              [Page 120]
Internet-Draft                    L2NM                         July 2021

   [RFC7297]  Boucadair, M., Jacquenet, C., and N. Wang, "IP
              Connectivity Provisioning Profile (CPP)", RFC 7297,
              DOI 10.17487/RFC7297, July 2014,
              <https://www.rfc-editor.org/info/rfc7297>.

   [RFC7951]  Lhotka, L., "JSON Encoding of Data Modeled with YANG",
              RFC 7951, DOI 10.17487/RFC7951, August 2016,
              <https://www.rfc-editor.org/info/rfc7951>.

   [RFC8309]  Wu, Q., Liu, W., and A. Farrel, "Service Models
              Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
              <https://www.rfc-editor.org/info/rfc8309>.

   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
              <https://www.rfc-editor.org/info/rfc8340>.

   [RFC8343]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
              <https://www.rfc-editor.org/info/rfc8343>.

   [RFC8345]  Clemm, A., Medved, J., Varga, R., Bahadur, N.,
              Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
              Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
              2018, <https://www.rfc-editor.org/info/rfc8345>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC8453]  Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
              Abstraction and Control of TE Networks (ACTN)", RFC 8453,
              DOI 10.17487/RFC8453, August 2018,
              <https://www.rfc-editor.org/info/rfc8453>.

   [RFC8519]  Jethanandani, M., Agarwal, S., Huang, L., and D. Blair,
              "YANG Data Model for Network Access Control Lists (ACLs)",
              RFC 8519, DOI 10.17487/RFC8519, March 2019,
              <https://www.rfc-editor.org/info/rfc8519>.

   [RFC8584]  Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
              J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
              VPN Designated Forwarder Election Extensibility",
              RFC 8584, DOI 10.17487/RFC8584, April 2019,
              <https://www.rfc-editor.org/info/rfc8584>.

Barguil, et al.         Expires January 29, 2022              [Page 121]
Internet-Draft                    L2NM                         July 2021

   [RFC8792]  Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
              "Handling Long Lines in Content of Internet-Drafts and
              RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
              <https://www.rfc-editor.org/info/rfc8792>.

   [RFC8960]  Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A
              YANG Data Model for MPLS Base", RFC 8960,
              DOI 10.17487/RFC8960, December 2020,
              <https://www.rfc-editor.org/info/rfc8960>.

   [RFC8969]  Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and
              L. Geng, "A Framework for Automating Service and Network
              Management with YANG", RFC 8969, DOI 10.17487/RFC8969,
              January 2021, <https://www.rfc-editor.org/info/rfc8969>.

Appendix A.  Examples

   This section includes a non-exhaustive list of examples to illustrate
   the use of the L2NM.

   In the following subsections, only the content of the message bodies
   is shown using JSON notations [RFC7951].

   The examples use the folding defined in [RFC8792] for long lines.

A.1.  BGP-based VPLS

   This section provides an example to illustrate how the L2NM can be
   used to mange BGP-based VPLS.  We consider the sample VPLS service
   delivered using the architecture depicted in Figure 23.  In
   accordance with [RFC4761], we assume that a full mesh is established
   between all PEs.  The details about such full mesh are not detailed
   here.

                    +-----+      +--------------+   +-----+
       +----+       | PE1 |======|              |===| PE3 |       +----+
       | CE1+-------+     |      |              |   |     +-------+ CE3|
       +----+       +-----+      |              |   +-----+       +----+
                                 |     Core     |
       +----+       +-----+      |              |   +-----+       +----+
       |CE2 +-------+     |      |              |   |     +-------+ CE4|
       +----+       | PE2 |======|              |===| PE4 |       +----+
                    +-----+      +--------------+   +-----+

                       Figure 23: An Example of VPLS

Barguil, et al.         Expires January 29, 2022              [Page 122]
Internet-Draft                    L2NM                         July 2021

   Figure 24 show an example of a message body used to configured a VPLS
   instance using the L2NM.  In this example, BGP is used for both auto-
   discovery and signaling.  The 'signaling-type' data node is set to
   'vpn-common:bgp-signaling'.

   {
     "ietf-l2vpn-ntw:vpn-services": {
       "vpn-service": [
         {
           "vpn-id": "vpls7714825356",
           "description": "Sample BGP-based VPLS",
           "customer-name": "customer_7714825356",
           "vpn-type": "vpn-common:vpls",
           "bgp-ad-enabled": true,
           "signaling-type": "vpn-common:bgp-signaling",
           "global-parameters-profiles": {
             "global-parameters-profile": [
               {
                 "profile-id": "simple-profile",
                 "local-autonomous-system": 65550,
                 "mtu": 1518,
                 "rd-suffix": "1",
                 "vpn-targets": {
                   "vpn-target": [
                     {
                       "id": "1",
                       "route-targets": [
                         "0:65550:1"
                       ],
                       "route-target-type": "both"
                     }
                   ]
                 }
               }
             ]
           },
           "vpn-node": [
             {
               "vpn-node-id": "pe1",
               "ne-id": "198.51.100.1",
               "active-global-parameters-profile": {
                 "global-parameters-profile": [
                   {
                     "profile-id": "simple-profile"
                   }
                 ]
               },
               "bgp-auto-discovery": {

Barguil, et al.         Expires January 29, 2022              [Page 123]
Internet-Draft                    L2NM                         July 2021

                 "vpn-id": "1"
               },
               "signaling-option": {
                 "pw-encapsulation-type": "iana-bgp-l2-encaps:ethernet-\
                  tagged-mode",
                 "vpls-instance": {
                   "vpls-edge-id": "1",
                   "vpls-edge-id-range": "100"
                 }
               },
               "vpn-network-access": [
                 {
                   "id": "1/1/1.1",
                   "interface-id": "1/1/1",
                   "description": "Interface to CE1",
                   "global-parameters-profile": "simple-profile",
                   "status": {
                     "admin-status": {
                       "status": "vpn-common:admin-state-up"
                     }
                   },
                   "connection": {
                     "encapsulation": {
                       "type": "dot1q",
                       "dot1q": {
                         "cvlan-id": 1
                       }
                     }
                   }
                 }
               ]
             },
             {
               "vpn-node-id": "pe2",
               "ne-id": "198.51.100.2",
               "active-global-parameters-profile": {
                 "global-parameters-profile": [
                   {
                     "profile-id": "simple-profile"
                   }
                 ]
               },
               "bgp-auto-discovery": {
                 "vpn-id": "1"
               },
               "signaling-option": {
                 "pw-encapsulation-type": "iana-bgp-l2-encaps:ethernet-\
                  tagged-mode",

Barguil, et al.         Expires January 29, 2022              [Page 124]
Internet-Draft                    L2NM                         July 2021

                 "vpls-instance": {
                   "vpls-edge-id": "2",
                   "vpls-edge-id-range": "100"
                 }
               },
               "vpn-network-access": [
                 {
                   "id": "1/1/1.1",
                   "interface-id": "1/1/1",
                   "description": "Interface to CE2",
                   "global-parameters-profile": "simple-profile",
                   "status": {
                     "admin-status": {
                       "status": "vpn-common:admin-state-up"
                     }
                   },
                   "connection": {
                     "encapsulation": {
                       "type": "dot1q",
                       "dot1q": {
                         "cvlan-id": 1
                       }
                     }
                   }
                 }
               ]
             },
             {
               "vpn-node-id": "pe3",
               "ne-id": "198.51.100.3",
               "active-global-parameters-profile": {
                 "global-parameters-profile": [
                   {
                     "profile-id": "simple-profile"
                   }
                 ]
               },
               "bgp-auto-discovery": {
                 "vpn-id": "1"
               },
               "signaling-option": {
                 "pw-encapsulation-type": "iana-bgp-l2-encaps:ethernet-\
                  tagged-mode",
                 "vpls-instance": {
                   "vpls-edge-id": "3",
                   "vpls-edge-id-range": "100"
                 }
               },

Barguil, et al.         Expires January 29, 2022              [Page 125]
Internet-Draft                    L2NM                         July 2021

               "vpn-network-access": [
                 {
                   "id": "1/1/1.1",
                   "interface-id": "1/1/1",
                   "description": "Interface to CE3",
                   "global-parameters-profile": "simple-profile",
                   "status": {
                     "admin-status": {
                       "status": "vpn-common:admin-state-up"
                     }
                   },
                   "connection": {
                     "encapsulation": {
                       "type": "dot1q",
                       "dot1q": {
                         "cvlan-id": 1
                       }
                     }
                   }
                 }
               ]
             },
             {
               "vpn-node-id": "pe4",
               "ne-id": "198.51.100.4",
               "active-global-parameters-profile": {
                 "global-parameters-profile": [
                   {
                     "profile-id": "simple-profile"
                   }
                 ]
               },
               "bgp-auto-discovery": {
                 "vpn-id": "1"
               },
               "signaling-option": {
                 "pw-encapsulation-type": "iana-bgp-l2-encaps:ethernet-\
                  tagged-mode",
                 "vpls-instance": {
                   "vpls-edge-id": "4",
                   "vpls-edge-id-range": "100"
                 }
               },
               "vpn-network-access": [
                 {
                   "id": "1/1/1.1",
                   "interface-id": "1/1/1",
                   "description": "Interface to CE4",

Barguil, et al.         Expires January 29, 2022              [Page 126]
Internet-Draft                    L2NM                         July 2021

                   "global-parameters-profile": "simple-profile",
                   "status": {
                     "admin-status": {
                       "status": "vpn-common:admin-state-up"
                     }
                   },
                   "connection": {
                     "encapsulation": {
                       "type": "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

   Let's consider the simple architecture depicted in Figure 25 to offer
   a VPWS between CE1 and CE2.  The service uses BGP for auto-discovery
   and LDP for signaling.

                    +-----+      +--------------+   +-----+
       +----+       | PE1 |======|              |===| PE2 |       +----+
       | CE1+-------+     |      |     Core     |   |     +-------+ CE2|
       +----+       +-----+      +--------------+   +-----+       +----+
              site1                                          site2

                       Figure 25: An Example of VPLS

   {
     "ietf-l2vpn-ntw:vpn-services": {
       "vpn-service": [
         {
           "vpn-id": "vpws12345",
           "description": "Simple VPWS",
           "customer-name": "customer_12345",
           "vpn-type": "vpn-common:vpws",
           "bgp-ad-enabled": true,

Barguil, et al.         Expires January 29, 2022              [Page 127]
Internet-Draft                    L2NM                         July 2021

           "signaling-type": "vpn-common:ldp-signaling",
           "global-parameters-profiles": {
             "global-parameters-profile": [
               {
                 "profile-id": "simple-profile",
                 "local-autonomous-system": 65550,
                 "rd-auto": {
                   "auto": [
                     null
                   ]
                 },
                 "vpn-targets": {
                   "vpn-target": [
                     {
                       "id": "1",
                       "route-targets": [
                         "0:65550:1"
                       ]
                     }
                   ]
                 }
               }
             ]
           },
           "vpn-node": [
             {
               "vpn-node-id": "pe1",
               "ne-id": "2001:db8:100::1",
               "active-global-parameters-profile": {
                 "global-parameters-profile": [
                   {
                     "profile-id": "simple-profile"
                   }
                 ]
               },
               "vpn-network-access": [
                 {
                   "id": "1/1/1.1",
                   "interface-id": "1/1/1",
                   "description": "Interface to CE1",
                   "global-parameters-profile": "simple-profile",
                   "status": {
                     "admin-status": {
                       "status": "vpn-common:admin-state-up"
                     }
                   },
                   "bgp-auto-discovery": {
                     "vpn-id": 587

Barguil, et al.         Expires January 29, 2022              [Page 128]
Internet-Draft                    L2NM                         July 2021

                   },
                   "signaling-option": {
                     "mtu-pw": 1500,
                     "ldp-or-l2tp": {
                       "saii": 1,
                       "remote-targets": [
                         {
                           "taii": 2
                         }
                       ]
                     },
                     "pw-type": "ethernet"
                   }
                 }
               ]
             },
             {
               "vpn-node-id": "pe2",
               "ne-id": "2001:db8:200::1",
               "active-global-parameters-profile": {
                 "global-parameters-profile": [
                   {
                     "profile-id": "simple-profile"
                   }
                 ]
               },
               "vpn-network-access": [
                 {
                   "id": "5/1/1.1",
                   "interface-id": "5/1/1",
                   "description": "Interface to CE2",
                   "global-parameters-profile": "simple-profile",
                   "status": {
                     "admin-status": {
                       "status": "vpn-common:admin-state-up"
                     }
                   },
                   "bgp-auto-discovery": {
                     "vpn-id": 587
                   },
                   "signaling-option": {
                     "mtu-pw": 1500,
                     "ldp-or-l2tp": {
                       "saii": 2,
                       "remote-targets": [
                         {
                           "taii": 1
                         }

Barguil, et al.         Expires January 29, 2022              [Page 129]
Internet-Draft                    L2NM                         July 2021

                       ]
                     },
                     "pw-type": "ethernet"
                   }
                 }
               ]
             }
           ]
         }
       ]
     }
   }

   Figure 26: Example of L2NM Message Body to Configure a BGP-based VPWS
                            with LDP Signaling

A.3.  LDP-based VPLS

   This section provides an example to illustrate how the L2NM can be
   used to manage a VPLS with LDP signaling.  The connectivity between
   the CE and the PE is direct using Dot1q encapsulation.  We consider
   the sample service delivered using the architecture depicted in
   Figure 27.

                    +-----------  VPLS "1543" ------------+

                    +-----+      +--------------+   +-----+
        +----+      | PE1 |======|              |===| PE2 |       +----+
        | CE1 +-----+"450"|      |     MPLS     |   |"451"+-------+ CE2|
        +----+      +-----+      |              |   +-----+       +----+
                                 |     Core     |
                                 +--------------+

                  Figure 27: An Example of VPLS topology

   Figure 28 shows how the L2NM is used to instruct both PE1 and PE2 to
   use the targeted LDP session between them to establish the VPLS
   "1543" between the ends.  A single VPN service is created for this
   purpose.  Additionally, two VPN Nodes and each with a corresponding
   VPN network access is also created.

        {
          "l2vpn-ntw": {
            "vpn-services": {
              "vpn-service": {
                "vpn-id": "450",
                "vpn-name": "BANCO_EXAMPLE_CORP",

Barguil, et al.         Expires January 29, 2022              [Page 130]
Internet-Draft                    L2NM                         July 2021

                "vpn-description": "SEDE_CENTRO_450",
                "customer-name": "EXAMPLE",
                "vpn-type": "vpn-common:vpls",
                "vpn-service-topology": "vpn-common:hub-spoke",
                "bgp-ad-enabled": false,
                "signaling-type": "vpn-common:ldp-signaling",
                "global-parameters-profiles": {
                  "global-parameters-profile": {
                    "ce-vlan-preservation": "true",
                    "ce-vlan-cos-perservation": "true"
                  }
                },
                "vpn-nodes": [
                  {
                    "vpn-node": {
                      "vpn-node-id": "450",
                      "description": "SEDE_CENTRO_450",
                      "ne-id": "2001:db8:5::1",
                      "role": "vpn-common:hub-role",
                      "status": {
                        "admin-status": {
                          "status": "vpn-common:admin-up"
                        }
                      },
                      "ldp-or-l2tp": {
                        "signaling-option": [
                          {
                            "t-ldp-pw-type": "vpls-type"
                          }
                        ]
                      },
                      "ac-pw-list": [
                        {
                          "peer-addr": "2001:db8:50::1",
                          "vc-id": "1543"
                        }
                      ]
                    },
                    "vpn-network-accesses": {
                      "vpn-network-access": {
                        "id": "4508671287",
                        "description": "VPN_450_SNA",
                        "interface-id": "gigabithethernet0/0/1",
                        "status": {
                          "admin-status": {
                            "status": "vpn-common:admin-up"
                          }
                        },

Barguil, et al.         Expires January 29, 2022              [Page 131]
Internet-Draft                    L2NM                         July 2021

                        "connection": {
                          "l2-termination-point": "550",
                          "encapsulation": {
                            "type": "vpn-common:dot1q",
                            "dot1q": {
                              "tag-type": "vpn-common:c-vlan",
                              "cvlan-id": "550"
                            }
                          }
                        },
                        "service": {
                          "mtu": "1550",
                          "svc-inbound-bandwidth": {
                            "inbound-bandwidth": {
                              "type": "vpn-common:bw-per-service",
                              "cir": "20480000"
                            }
                          },
                          "svc-outbound-bandwidth": {
                            "outbound-bandwidth": {
                              "type": "vpn-common:bw-per-port",
                              "cir": "20480000"
                            }
                          },
                          "qos": {
                            "qos-profile": {
                              "qos-profile": {
                                "profile": "QoS_Profile_A",
                                "direction": "vpn-common:both"
                              }
                            }
                          }
                        }
                      }
                    }
                  },
                  {
                    "vpn-node": {
                      "vpn-node-id": "451",
                      "description": "SEDE_CHAPINERO_451",
                      "ne-id": "2001:db8:50::1",
                      "role": "vpn-common:spoke-role",
                      "status": {
                        "admin-status": {
                          "status": "vpn-common:admin-up"
                        }
                      },
                      "ldp-or-l2tp": {

Barguil, et al.         Expires January 29, 2022              [Page 132]
Internet-Draft                    L2NM                         July 2021

                        "signaling-option": [
                          {
                            "t-ldp-pw-type": "vpls-type"
                          }
                        ]
                      },
                      "ac-pw-list": [
                        {
                          "peer-addr": "2001:db8:5::1",
                          "vc-id": "1543"
                        }
                      ]
                    },
                    "vpn-network-accesses": {
                      "vpn-network-access": {
                        "id": "4508671288",
                        "description": "VPN_450_SNA",
                        "interface-id": "gigabithethernet0/0/1",
                        "status": {
                          "admin-status": {
                            "status": "vpn-common:admin-up"
                          }
                        },
                        "connection": {
                          "l2-termination-point": "550",
                          "encapsulation": {
                            "type": "vpn-common:dot1q",
                            "dot1q": {
                              "tag-type": "vpn-common:c-vlan",
                              "cvlan-id": "550"
                            }
                          }
                        },
                        "service": {
                          "mtu": "1550",
                          "svc-inbound-bandwidth": {
                            "inbound-bandwidth": {
                              "type": "vpn-common:bw-per-service",
                              "cir": "20480000"
                            }
                          },
                          "svc-outbound-bandwidth": {
                            "outbound-bandwidth": {
                              "type": "vpn-common:bw-per-port",
                              "cir": "20480000"
                            }
                          },
                          "qos": {

Barguil, et al.         Expires January 29, 2022              [Page 133]
Internet-Draft                    L2NM                         July 2021

                            "qos-profile": {
                              "qos-profile": {
                                "profile": "QoS_Profile_A",
                                "direction": "vpn-common:both"
                              }
                            }
                          }
                        }
                      }
                    }
                  }
                ]
              }
            }
          }
        }

        Figure 28: Example of L2NM Message Body for LDP-based VPLS

A.4.  VPWS-EVPN Service Instance

   Figure 29 depictes a sample architecture to offer VPWS-EVPN service
   between CE1 and CE2.  Both CEs are multi-homed.  BGP sessions are
   maintained between these PEs as per [RFC8214].  In this EVPN
   instance, an All-Active redundancy mode is used.

                    |<--------- EVPN Instance ----------->|
                    |                                     |
              |     V                                     V  |
              |     +-----+      +--------------+   +-----+  |
       +----+ |     | PE1 |======|              |===| PE3 |  |    +----+
       |    +-------+     |      |              |   |     +-------+    |
       |    | |     +-----+      |              |   +-----+  |    |    |
       | CE1| |                  |     Core     |            |    |CE2 |
       |    | |     +-----+      |              |   +-----+  |    |    |
       |    +-------+     |      |              |   |     +-------+    |
       +----+ |     | PE2 |======|              |===| PE4 |  |    +----+
            ^  ESI1 +-----+      +--------------+   +-----+  ESI2    ^
            |                                                        |
            |<---------------- Emulated Service -------------------->|

                    Figure 29: An Example of VPWS-EVPN

   Let's first suppose that the following ES was created (Figure 30).

Barguil, et al.         Expires January 29, 2022              [Page 134]
Internet-Draft                    L2NM                         July 2021

   {
     "ietf-l2vpn-ntw:ethernet-segments": {
       "ethernet-segment": [
         {
           "name": "esi1",
           "ethernet-segment-identifier": "00:11:11:11:11:11:11:\
             11:11:11",
           "esi-redundancy-mode": "all-active"
         },
         {
           "name": "esi2",
           "ethernet-segment-identifier": "00:22:22:22:22:22:22:\
             22:22:22",
           "esi-redundancy-mode": "all-active"
         }
       ]
     }
   }

     Figure 30: Example of L2NM Message Body to Configure an Ethernet
                                  Segment

   Figure 29 shows a simplified configuration to illustrate the use of
   the L2NM to configured VPWS-EVPN instance.

   {
     "ietf-l2vpn-ntw:vpn-services": {
       "vpn-service": [
         {
           "vpn-id": "vpws15432855",
           "description": "Sample VPWS-EVPN",
           "customer-name": "customer_15432855",
           "vpn-type": "vpn-common:vpws-evpn",
           "bgp-ad-enabled": true,
           "signaling-type": "vpn-common:bgp-signaling",
           "global-parameters-profiles": {
             "global-parameters-profile": [
               {
                 "profile-id": "simple-profile",
                 "local-autonomous-system": 65550,
                 "rd-suffix": "1",
                 "vpn-targets": {
                   "vpn-target": [
                     {
                       "id": "1",
                       "route-targets": [
                         "0:65550:1"
                       ],

Barguil, et al.         Expires January 29, 2022              [Page 135]
Internet-Draft                    L2NM                         July 2021

                       "route-target-type": "both"
                     }
                   ]
                 }
               }
             ]
           },
           "vpn-node": [
             {
               "vpn-node-id": "pe1",
               "ne-id": "198.51.100.1",
               "active-global-parameters-profile": {
                 "global-parameters-profile": [
                   {
                     "profile-id": "simple-profile"
                   }
                 ]
               },
               "vpn-network-access": [
                 {
                   "id": "1/1/1.1",
                   "interface-id": "1/1/1",
                   "description": "Interface to CE1",
                   "global-parameters-profile": "simple-profile",
                   "status": {
                     "admin-status": {
                       "status": "vpn-common:admin-state-up"
                     }
                   },
                   "connection": {
                     "encapsulation": {
                       "type": "dot1q",
                       "dot1q": {
                         "cvlan-id": 1
                       }
                     }
                   },
                   "vpws-service-instance": {
                     "local-vpws-service-instance": 1111,
                     "remote-vpws-service-instance": 1112
                   },
                   "group": [
                     {
                       "group-id": "gr1",
                       "ethernet-segment-identifier": "esi1"
                     }
                   ]
                 }

Barguil, et al.         Expires January 29, 2022              [Page 136]
Internet-Draft                    L2NM                         July 2021

               ]
             },
             {
               "vpn-node-id": "pe2",
               "ne-id": "198.51.100.2",
               "active-global-parameters-profile": {
                 "global-parameters-profile": [
                   {
                     "profile-id": "simple-profile"
                   }
                 ]
               },
               "vpn-network-access": [
                 {
                   "id": "1/1/1.1",
                   "interface-id": "1/1/1",
                   "description": "Interface to CE1",
                   "global-parameters-profile": "simple-profile",
                   "status": {
                     "admin-status": {
                       "status": "vpn-common:admin-state-up"
                     }
                   },
                   "connection": {
                     "encapsulation": {
                       "type": "dot1q",
                       "dot1q": {
                         "cvlan-id": 1
                       }
                     }
                   },
                   "vpws-service-instance": {
                     "local-vpws-service-instance": 1111,
                     "remote-vpws-service-instance": 1112
                   },
                   "group": [
                     {
                       "group-id": "gr1",
                       "ethernet-segment-identifier": "esi1"
                     }
                   ]
                 }
               ]
             },
             {
               "vpn-node-id": "pe3",
               "ne-id": "198.51.100.3",
               "active-global-parameters-profile": {

Barguil, et al.         Expires January 29, 2022              [Page 137]
Internet-Draft                    L2NM                         July 2021

                 "global-parameters-profile": [
                   {
                     "profile-id": "simple-profile"
                   }
                 ]
               },
               "vpn-network-access": [
                 {
                   "id": "1/1/1.1",
                   "interface-id": "1/1/1",
                   "description": "Interface to CE2",
                   "global-parameters-profile": "simple-profile",
                   "status": {
                     "admin-status": {
                       "status": "vpn-common:admin-state-up"
                     }
                   },
                   "connection": {
                     "encapsulation": {
                       "type": "dot1q",
                       "dot1q": {
                         "cvlan-id": 1
                       }
                     }
                   },
                   "vpws-service-instance": {
                     "local-vpws-service-instance": 1112,
                     "remote-vpws-service-instance": 1111
                   },
                   "group": [
                     {
                       "group-id": "gr1",
                       "ethernet-segment-identifier": "esi2"
                     }
                   ]
                 }
               ]
             },
             {
               "vpn-node-id": "pe4",
               "ne-id": "198.51.100.4",
               "active-global-parameters-profile": {
                 "global-parameters-profile": [
                   {
                     "profile-id": "simple-profile"
                   }
                 ]
               },

Barguil, et al.         Expires January 29, 2022              [Page 138]
Internet-Draft                    L2NM                         July 2021

               "vpn-network-access": [
                 {
                   "id": "1/1/1.1",
                   "interface-id": "1/1/1",
                   "description": "Interface to CE2",
                   "global-parameters-profile": "simple-profile",
                   "status": {
                     "admin-status": {
                       "status": "vpn-common:admin-state-up"
                     }
                   },
                   "connection": {
                     "encapsulation": {
                       "type": "dot1q",
                       "dot1q": {
                         "cvlan-id": 1
                       }
                     }
                   },
                   "vpws-service-instance": {
                     "local-vpws-service-instance": 1112,
                     "remote-vpws-service-instance": 1111
                   },
                   "group": [
                     {
                       "group-id": "gr1",
                       "ethernet-segment-identifier": "esi2"
                     }
                   ]
                 }
               ]
             }
           ]
         }
       ]
     }
   }

     Figure 31: Example of L2NM Message Body to Configure a VPWS-EVPN
                                 Instance

A.5.  Automatic ESI Assignment

   This section provides an example to illustrate how the L2NM can be
   used to manage ESI auto-assignment.  We consider the sample EVPN
   service delivered using the architecture depicted in Figure 32.

Barguil, et al.         Expires January 29, 2022              [Page 139]
Internet-Draft                    L2NM                         July 2021

              ES
              |     +-----+      +--------------+   +-----+
       +----+ |     | PE1 |======|              |===| PE3 |       +----+
       |    +-------+     |      |              |   |     +-------+ CE3|
       |    | |     +-----+      |              |   +-----+       +----+
       | CE1| |                  |     Core     |
       |    | |     +-----+      |              |   +-----+       +----+
       |    +-------+     |      |              |   |     +-------+ CE2|
       +----+ |     | PE2 |======|              |===| PE4 |       +----+
            LACP    +-----+      +--------------+   +-----+

             Figure 32: An Example of Automatic ESI Assignment

   Figure 33 and Figure 34 show how the L2NM is used to instruct both
   PE1 and PE2 to auto-assign the ESI to identify the ES used with CE1.
   In this example, we suppose that LACP is enabled and that a Type 1
   (T=0x01) is used as per Section 5 of [RFC7432].  Note that this
   example does not include all the details to configure the EVPN
   service, but focuses only on the ESI management part.

   {
     "ietf-l2vpn-ntw:ethernet-segments": {
       "ethernet-segment": [
         {
           "name": "esi1",
           "ethernet-segment-identifier": "esi-type-1",
           "esi-redundancy-mode": "all-active"
         }
       ]
     }
   }

      Figure 33: Example of L2NM Message Body to Auto-Assign Ethernet
                            Segment Identifiers

   {
     "ietf-l2vpn-ntw:vpn-services": {
       "vpn-service": [
         {
           "vpn-id": "auto-esi-lacp",
           "description": "Sample to illustrate auto-ESI",
           "vpn-type": "vpn-common:vpls-evpn",
           "vpn-node": [
             {
               "vpn-node-id": "pe1",
               "ne-id": "198.51.100.1",
               "vpn-network-access": [
                 {

Barguil, et al.         Expires January 29, 2022              [Page 140]
Internet-Draft                    L2NM                         July 2021

                   "id": "1/1/1.1",
                   "interface-id": "1/1/1",
                   "description": "Interface to CE1",
                   "global-parameters-profile": "simple-profile",
                   "status": {
                     "admin-status": {
                       "status": "vpn-common:admin-state-up"
                     }
                   },
                   "connection": {
                     "lag-interface": {
                       "lag-interface": [
                         {
                           "lag-interface-number": 1,
                           "lacp": {
                             "lacp-state": true,
                             "system-id": "11:00:11:00:11:11",
                             "admin-key": 154
                           }
                         }
                       ]
                     }
                   },
                   "group": [
                     {
                       "group-id": "gr1",
                       "ethernet-segment-identifier": "esi1"
                     }
                   ]
                 }
               ]
             },
             {
               "vpn-node-id": "pe2",
               "ne-id": "198.51.100.2",
               "vpn-network-access": [
                 {
                   "id": "2/2/2.5",
                   "interface-id": "2/2/2",
                   "description": "Interface to CE1",
                   "status": {
                     "admin-status": {
                       "status": "vpn-common:admin-state-up"
                     }
                   },
                   "connection": {
                     "lag-interface": {
                       "lag-interface": [

Barguil, et al.         Expires January 29, 2022              [Page 141]
Internet-Draft                    L2NM                         July 2021

                         {
                           "lag-interface-number": 1,
                           "lacp": {
                             "lacp-state": true,
                             "system-id": "11:00:11:00:11:11",
                             "admin-key": 154
                           }
                         }
                       ]
                     }
                   },
                   "group": [
                     {
                       "group-id": "gr1",
                       "ethernet-segment-identifier": "esi1"
                     }
                   ]
                 }
               ]
             }
           ]
         }
       ]
     }
   }

    Figure 34: An Example of L2NM Message Body for ESI Auto-Assignement

   The auto-assigned ESI can be retrieved using, e.g., a GET RESTCONF
   method.  The assigned value will be then returned as shown in the
   'esi-auto' data node in Figure 35.

Barguil, et al.         Expires January 29, 2022              [Page 142]
Internet-Draft                    L2NM                         July 2021

   {
     "ietf-l2vpn-ntw:ethernet-segments": {
       "ethernet-segment": [
         {
           "name": "esi1",
           "ethernet-segment-identifier": "esi-type-1",
           "esi-auto": {
             "auto-ethernet-segment-identifier": "01:11:00:11:00:11:\
                 11:9A:00:00"
           },
           "esi-redundancy-mode": "all-active"
         }
       ]
     }
   }

    Figure 35: An Example of L2NM Message Body to Retrieve the Assigned
                                    ESI

A.6.  VPN Network Access Precedence

   In reference to the example depicted in Figure 36, an L2VPN service
   involves two VPN network accesses to sites that belong to the same
   customer.

   +--------------+
   |VPN-NODE      |
   |           +--+-------+
   |           | NET-ACC-2| Primacy
   |           |          +------------------
   |           +--+-------+
   |              |
   |           +--+-------+
   |           | NET-ACC-1| Backup
   |           |          +------------------
   |           +--+-------+
   |              |
   +--------------+

            Figure 36: Example of Multiple VPN Network Accesses

   In order to tag one of these VPN network accesses as "primary" and
   the other one as "backup", Figure 37 shows an excerpt of the
   corresponding L2NM configuration.  In such as configuration, both
   accesses are bound to the same "group-id" and the "precedence" data
   node set as function of the intended role of each access (primary or
   backup).

Barguil, et al.         Expires January 29, 2022              [Page 143]
Internet-Draft                    L2NM                         July 2021

   {
     "vpn-services": {
       "vpn-service": {
         "vpn-id": "Sample-Service",
         "vpn-nodes": {
           "vpn-node": {
             "vpn-node-id": "VPN-NODE",
             "vpn-network-accesses": {
               "vpn-network-access": [
                 {
                   "id": "NET-ACC-1",
                   "group": {
                     "group-id": "1",
                     "precedence": "primary"
                   }
                 },
                 {
                   "id": "NET-ACC-1",
                   "group": {
                     "group-id": "1",
                     "precedence": "backup"
                   }
                 }
               ]
             }
           }
         }
       }
     }
   }

   Figure 37: Example of Message Body to Associate Priority Levels with
                           VPN Network Accesses

Appendix B.  Initial BGP Layer 2 Encapsulation Types

Barguil, et al.         Expires January 29, 2022              [Page 144]
Internet-Draft                    L2NM                         July 2021

             Value Description                       Reference
             ===== ================================  =========
             1     Frame Relay                       [RFC4446]
             2     ATM AAL5 SDU VCC transport        [RFC4446]
             3     ATM transparent cell transport    [RFC4816]
             4     Ethernet (VLAN) Tagged Mode       [RFC4448]
             5     Ethernet Raw Mode                 [RFC4448]
             6     Cisco HDLC                        [RFC4618]
             7     PPP                               [RFC4618]
             8     SONET/SDH Circuit Emulation       [RFC4842]
                   Service
             9     ATM n-to-one VCC cell transport   [RFC4717]
             10    ATM n-to-one VPC cell transport   [RFC4717]
             11    IP Layer 2 Transport              [RFC3032]
             15    Frame Relay Port mode             [RFC4619]
             17    Structure-agnostic E1 over packet [RFC4553]
             18    Structure-agnostic T1 (DS1) over  [RFC4553]
                   packet
             19    VPLS                              [RFC4761]
             20    Structure-agnostic T3 (DS3) over  [RFC4553]
                   packet
             21    Nx64kbit/s Basic Service using    [RFC5086]
                   Structure-aware
             25    Frame Relay DLCI                  [RFC4619]
             40    Structure-agnostic E3 over packet [RFC4553]
             41    Octet-aligned payload for         [RFC4553]
                   Structure-agnostic DS1 circuits
             42    E1 Nx64kbit/s with CAS using      [RFC5086]
                   Structure-aware
             43    DS1 (ESF) Nx64kbit/s with CAS     [RFC5086]
                   using Structure-aware
             44    DS1 (SF) Nx64kbit/s with CAS      [RFC5086]
                   using Structure-aware

Appendix C.  Initial PW Types

Barguil, et al.         Expires January 29, 2022              [Page 145]
Internet-Draft                    L2NM                         July 2021

       PW Type Description                       Reference
       ======= ================================  =========
       0x0001  Frame Relay DLCI                  [RFC4619]
       0x0002  ATM AAL5 SDU VCC transport
       0x0003  ATM transparent cell transport    [RFC4717]
       0x0004  Ethernet Tagged Mode              [RFC4448]
       0x0005  Ethernet                          [RFC4448]
       0x0006  HDLC                              [RFC4618]
       0x0007  PPP                               [RFC4618]
       0x0008  SONET/SDH Circuit Emulation
               Service Over MPLS Encapsulation   [RFC5143]
       0x0009  ATM n-to-one VCC cell transport   [RFC4717]
       0x000A  ATM n-to-one VPC cell transport   [RFC4717]
       0x000B  IP Layer2 Transport               [RFC3032]
       0x000C  ATM one-to-one VCC Cell Mode      [RFC4717]
       0x000D  ATM one-to-one VPC Cell Mode      [RFC4717]
       0x000E  ATM AAL5 PDU VCC transport        [RFC4717]
       0x000F  Frame-Relay Port mode             [RFC4619]
       0x0010  SONET/SDH Circuit Emulation       [RFC4842]
               Reference Packet
       0x0011  Structure-agnostic E1 over        [RFC4553]
               Packet
       0x0012  Structure-agnostic T1 (DS1)       [RFC4553]
               over Packet
       0x0013  Structure-agnostic E3 over        [RFC4553]
               Packet
       0x0014  Structure-agnostic T3 (DS3)       [RFC4553]
               over Packet
       0x0015  CESoPSN basic mode                [RFC5086]
       0x0016  TDMoIP AAL1 Mode                  [RFC5087]
       0x0017  CESoPSN TDM with CAS              [RFC5086]
       0x0018  TDMoIP AAL2 Mode                  [RFC5087]
       0x0019  Frame Relay DLCI                  [RFC4619]
       0x001A  ROHC Transport Header-compressed  [RFC5795][RFC4901]
               Packets
       0x001B  ECRTP Transport Header-compressed [RFC3545][RFC4901]
               Packets
       0x001C  IPHC Transport Header-compressed  [RFC2507][RFC4901]
               Packets
       0x001D  cRTP Transport Header-compressed  [RFC2508][RFC4901]
               Packets
       0x001E  ATM VP Virtual Trunk
       0x001F  FC Port Mode                      [RFC6307]
       0x7FFF  Wildcard                          [RFC4863]

Barguil, et al.         Expires January 29, 2022              [Page 146]
Internet-Draft                    L2NM                         July 2021

Acknowledgements

   During the discussions of this work, helpful comments, suggestions,
   and reviews were received from: Sergio Belotti, Italo Busi, Miguel
   Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque Gagliano,
   Christian Jacquenet, Kireeti Kompella, Julian Lucek, Moti
   Morgenstern, Erez Segev, and Tom Petch.  Many thanks to them.

   Luay Jalil, Jichun Ma, Daniel King, and Zhang Guiyu contributed to an
   early version of this document.

   Thanks to Yingzhen Qu for the rtgdir review.

   This work is partially supported by the European Commission under
   Horizon 2020 grant agreement number 101015857 Secured autonomic
   traffic management for a Tera of SDN flows (Teraflow).

Contributors

   Victor Lopez
   Nokia
   Email: victor.lopez@nokia.com

   Qin Wu
   Huawei
   Email: bill.wu@huawei.com

   Raul Arco
   Nokia
   Email: raul.arco@nokia.com

Authors' Addresses

   Samier Barguil
   Telefonica
   Madrid
   ES

   Email: samier.barguilgiraldo.ext@telefonica.com

   Oscar Gonzalez de Dios (editor)
   Telefonica
   Madrid
   ES

   Email: oscar.gonzalezdedios@telefonica.com

Barguil, et al.         Expires January 29, 2022              [Page 147]
Internet-Draft                    L2NM                         July 2021

   Mohamed Boucadair (editor)
   Orange
   Rennes
   France

   Email: mohamed.boucadair@orange.com

   Luis Angel Munoz
   Vodafone
   ES

   Email: luis-angel.munoz@vodafone.com

Barguil, et al.         Expires January 29, 2022              [Page 148]