OPSAWG                                                        S. Barguil
Internet-Draft                                  O. Gonzalez de Dios, Ed.
Intended status: Standards Track                              Telefonica
Expires: September 11, October 24, 2021                              M. Boucadair, Ed.
                                                                  Orange
                                                                L. Munoz
                                                                Vodafone
                                                               A. Aguado
                                                                   Nokia
                                                          March 10,
                                                          April 22, 2021

                    A Layer 3 VPN Network YANG Model
                     draft-ietf-opsawg-l3sm-l3nm-07
                     draft-ietf-opsawg-l3sm-l3nm-08

Abstract

   This document defines a an L3VPN Network YANG Model (L3NM) that can be
   used for the provisioning of Layer 3 Virtual Private Network (VPN)
   services within a service provider network.  The model provides a
   network-centric view of L3VPN services.

   L3NM is meant to be used by a network controller to derive the
   configuration information that will be sent to relevant network
   devices.  The model can also facilitate the communication between a
   service orchestrator and a network controller/orchestrator.

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 3 VPN Network Model";

   o  reference: RFC XXXX

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

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

Status of This Memo

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

   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 September 11, October 24, 2021.

Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  L3NM Reference Architecture . . . . . . . . . . . . . . . . .   7
   5.  Relation with other YANG Models . . . . . . . . . . . . . . .  10
   6.  Sample Uses of the L3NM Data Model  . . . . . . . . . . . . .  11
     6.1.  Enterprise Layer 3 VPN Services . . . . . . . . . . . . .  11
     6.2.  Multi-Domain Resource Management  . . . . . . . . . . . .  11  12
     6.3.  Management of Multicast Services  . . . . . . . . . . . .  12
   7.  Description of the L3NM YANG Module . . . . . . . . . . . . .  12
     7.1.  Overall Structure of the Module . . . . . . . . . . . . .  13
     7.2.  VPN Profiles  . . . . . . . . . . . . . . . . . . . . . .  13
     7.3.  VPN Services  . . . . . . . . . . . . . . . . . . . . . .  14  15
     7.4.  Import/Export  VPN Instance Profiles . . . . . . . . . . . . . . . . .  17 .  18
     7.5.  VPN Nodes . . . . . . . . . . . . . . . . . . . . . . . .  19  20
     7.6.  VPN Network Access  . . . . . . . . . . . . . . . . . . .  23
       7.6.1.  Connection  . . . . . . . . . . . . . . . . . . . . .  25  26
       7.6.2.  IP Connections Connection . . . . . . . . . . . . . . . . . . .  26 .  27
       7.6.3.  CE-PE Routing Protocols . . . . . . . . . . . . . . .  29  31
       7.6.4.  OAM . . . . . . . . . . . . . . . . . . . . . . . . .  40  43
       7.6.5.  Security  . . . . . . . . . . . . . . . . . . . . . .  41  44
       7.6.6.  Services  . . . . . . . . . . . . . . . . . . . . . .  42  45
     7.7.  Multicast . . . . . . . . . . . . . . . . . . . . . . . .  47  51
   8.  L3NM YANG Module  . . . . . . . . . . . . . . . . . . . . . .  52  55
   9.  IANA  Security Considerations . . . . . . . . . . . . . . . . . . . . . 104 115
   10. Security IANA Considerations . . . . . . . . . . . . . . . . . . . 104 . . 117
   11. Acknowledgements References  . . . . . . . . . . . . . . . . . . . . . . 105
   12. Contributors . . . 117
     11.1.  Normative References . . . . . . . . . . . . . . . . . . 117
     11.2.  Informative References . . . 106
   13. References . . . . . . . . . . . . . . 121
   Appendix A.  L3VPN Examples . . . . . . . . . . . . . 106
     13.1.  Normative References . . . . . . 124
     A.1.  4G VPN Provisioning Example . . . . . . . . . . . . 106
     13.2.  Informative References . . . 124
     A.2.  Loopback Interface  . . . . . . . . . . . . . . 109
   Appendix A.  L3VPN Examples . . . . . 130
     A.3.  Multicast VPN Provisioning Example  . . . . . . . . . . . 130
   Appendix B.  Implementation Status  . . . . 113
     A.1.  4G VPN Provisioning Example . . . . . . . . . . . 135
     B.1.  Nokia Implementation  . . . . 113
     A.2.  Multicast VPN Provisioning Example . . . . . . . . . . . 119
   Appendix B. . . . 135
     B.2.  Huawei Implementation Status . . . . . . . . . . . . . . . 123
     B.1.  Nokia Implementation . . . 135
     B.3.  Infinera Implementation . . . . . . . . . . . . . . . . . 123
     B.2.  Huawei 135
     B.4.  Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 135
   Acknowledgements  . . 123
     B.3.  Infinera Implementation . . . . . . . . . . . . . . . . . 124
     B.4.  Ribbon-ECI Implementation . . . . . 136
   Contributors  . . . . . . . . . . . 124 . . . . . . . . . . . . . . . 136
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 124 136

1.  Introduction

   [RFC8299] defines a Layer 3 Virtual Private Network Service YANG data
   Model (L3SM) that can be used for communication between customers and
   network operators.  Such model is focused on describing the customer
   view of the Virtual Private Network (VPN) services and provides an
   abstracted view of the customer's requested services.  That approach
   limits the usage of the L3SM to the role of a Customer Service Model customer service model
   (as per [RFC8309]).

   This document defines a YANG module called L3VPN Network Model
   (L3NM).  The L3NM is aimed at providing a network-centric view of
   Layer 3 (L3) VPN services.  This data model can be used to facilitate
   communication between the service orchestrator (or a network
   operator) and the network
   controller/orchestrator by allowing for more network-centric
   information to be included.  It enables further
   capabilities, capabilities such as
   resource management or to serve serves as a multi-
   domain multi-domain orchestration
   interface, where logical resources (such as route targets or route
   distinguishers) must be coordinated.

   This document uses the common VPN YANG module defined in
   [I-D.ietf-opsawg-vpn-common].

   This document does not obsolete [RFC8299].  These two modules are
   used for similar objectives but with different scopes and views.

   The L3NM YANG module is was initially built with a prune and extend
   approach, taking as a starting points the YANG module described in
   [RFC8299].  Nevertheless, the L3NM is not defined as an augment to
   L3SM because a specific structure is required to meet network-
   oriented L3 needs.

   Some of the information captured in the L3SM can be passed by the
   Orchestrator
   orchestrator in the L3NM (e.g., customer) or be used to fed feed some of
   the L3NM attributes (e.g., actual forwarding policies).  Some of the
   information captured in L3SM may be maintained locally within the
   Orchestrator;
   orchestrator; which is in charge of maintaining the correspondence
   between a customer view and its network instantiation.  Likewise,
   some of the information captured and exposed using the L3NM can feed
   the service layer (e.g., capabilities) to drive VPN service order
   handling, and thus the L3SM.

   Section 5.1 of [RFC8969] illustrates how the L3NM can be used within
   the network management automation architecture.

   The L3NM does not attempt to address all deployment cases especially
   those where the L3VPN connectivity is supported through the
   coordination of different VPNs in different underlying networks.
   More complex deployment scenarios involving the coordination of
   different VPN instances and different technologies to provide an end-
   to-end VPN connectivity are addressed by complementary YANG modules,
   e.g., [I-D.evenwu-opsawg-yang-composed-vpn].

   L3NM focuses on BGP Provider Edge (PE) based Layer 3 VPNs as
   described in [RFC4026][RFC4110][RFC4364] and Multicast VPNs as
   described in [RFC6037][RFC6513][RFC7988]. [RFC6037][RFC6513].

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

2.  Terminology

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

   This document assumes that the reader is familiar with the contents
   of [RFC6241], [RFC7950], [RFC8299], [RFC8309], and [RFC8453] and uses
   the terminology defined in those documents.

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

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

   This document makes use of the following terms:

   Layer 3 VPN Customer Service Model (L3SM):  A YANG module that
      describes the service requirements of a an L3VPN that interconnects
      a set of sites from the point of view of the customer.  The
      customer service model does not provide details on the service
      provider network.  The L3VPN Customer Service customer service model is defined in
      [RFC8299].

   Layer 3 VPN Service Network Model (L3NM):  A YANG module that
      describes a VPN service in the service provider network.  It
      contains information of the service provider network and might
      include allocated resources.  It can be used by network
      controllers to manage and control the VPN service configuration in
      the service provider network.  The YANG module can be consumed by
      a service orchestrator to request a VPN service to a Network
      Controller. network
      controller.

   Service orchestrator:  A functional entity that interacts with the
      customer of a an L3VPN.  The service orchestrator interacts with the
      customer using the L3SM.  The service orchestrator is responsible
      of the Customer Edge (CE) - Provider Edge (PE) attachment
      circuits, the PE selection, and requesting the VPN service to the
      Network Controller.
      network controller.

   Network orchestrator:  A functional entity that is hierarchically
      intermediate between a service orchestrator and network
      nontrollers.
      controllers.  A network orchestrator can manage one or several
      network nontrollers. controllers.

   Network controller:  A functional entity responsible for the control
      and management of the service provider network.

   VPN node:  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.  As it is an abstraction, the
      network controller will take on how to implement a VPN node.  For
      example, typically, in a BGP-based VPN, a VPN node could be mapped
      into a Virtual Routing and Forwarding (VRF).

   VPN network access:  An abstraction that represents the network
      interfaces that are associated to a given VPN node.  Traffic
      coming from the VPN network access belongs to the VPN.  The
      attachment circuits (bearers) between CEs and PEs are terminated
      in the VPN network access.  A reference to the bearer is
      maintained to allow keeping the link between L3SM and L3NM. L3NM when
      both models are used in a given deployment.

   VPN site:   A VPN customer's location that is connected to the
      service provider network via a CE-PE link, which can access at
      least one VPN [RFC4176].

   VPN service provider:  A service provider that offers VPN-related
      services [RFC4176].

   Service provider network:  A network that is able to provide VPN-
      related services.

   The document is aimed at modeling BGP PE-based VPNs in a service
   provider network, so the terms defined in [RFC4026] and [RFC4176] are
   used.

3.  Acronyms

   The following acronyms are used in the document:

   ACL     Access Control List
   AS      Autonomous System
   ASM     Any-Source Multicast
   ASN     AS Number
   BSR     Bootstrap Router
   BFD     Bidirectional Forwarding Detection
   BGP     Border Gateway Protocol
   CE      Customer Edge
   IGMP    nternet    Internet Group Management Protocol
   L3VPN   Layer 3 Virtual Private Network
   L3SM    L3VPN Service Model
   L3NM    L3VPN Network Model
   MLD     Multicast Listener Discovery
   MSDP    Multicast Source Discovery Protocol
   MVPN    Multicast VPN
   NAT     Network Address Translation
   OAM     Operations, Administration, and Maintenance
   OSPF    Open Shortest Path First
   PE      Provider Edge
   PIM     Protocol Independent Multicast
   QoS     Quality of Service
   RD      Route Distinguisher
   RP      Rendez-vous Point
   RT      Route Target
   SA      Security Association
   SSM     Source-Specific Multicast
   VPN     Virtual Private Network
   VRF     Virtual Routing and Forwarding

4.  L3NM Reference Architecture

   Figure 1 depicts the reference architecture for the L3NM.  The figure
   is an expansion of the architecture presented in Section 5 of
   [RFC8299]; it decomposes the box marked "orchestration" in that
   section into three separate functional components: Service
   Orchestration, Network Orchestration, and Domain Orchestration.

   Although some deployments may choose to construct a monolithic
   orchestration component (covering both service and network matters),
   this document advocates for a clear separation between service and
   network orchestration components for the sake of better flexibility.
   Such design adheres to the L3VPN reference architecture defined in
   Section 1.3 of [RFC4176].  This separation relies upon a dedicated
   communication interface between these components and appropriate YANG
   module
   modules that reflect network-related information.  Such information (that
   is hidden to
   customers). customers.

   The intelligence for translating customer-facing information into
   network-centric one (and vice versa) is implementation specific.

   The terminology from [RFC8309] is introduced to show the distinction
   between the customer service model, the service delivery model, the
   network configuration model, and the device configuration model.  In
   that context, the "Domain Orchestration" and "Config Manager" roles
   may be performed by "Controllers".

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

                   Figure 1: L3NM Reference Architecture

   The customer may use a variety of means to request a service that may
   trigger the instantiation of a an L3NM.  The customer may use the L3SM
   or may rely upon more abstract models to request a service that relies upon an
   L3VPN service.  For example, the customer may supply an IP
   Connectivity Provisioning Profile (CPP) [RFC7297], an enhanced VPN
   (VPN+) service [I-D.ietf-teas-enhanced-vpn], or an IETF network slice [I-D.ietf-teas-ietf-network-slice-definition], or Abstraction
   and Control of TE Networks (ACTN) [RFC8453].
   service [I-D.ietf-teas-ietf-network-slices].

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

                       +----------------------------------+
                       | Customer                         |
                       | +-----------------------------+  |
                       | |             CNC             |  |
                       | +-----------------------------+  |
                       +----:-----------------------:-----+
                            :                       :
                            :
                       +----+-----------------------+-----+
                            |                       |
                            | L3SM                  :                  | L3SM
                            :                       :
                  +---------:---------+   +-------------------+
                            |                       |
                  +---------+---------+   +---------+---------+
                  | MDSC    :              |   |       MDSC        |
                  | +---------------+ |   |     (parent)      |
                  | |    Service    | |   +-------------------+   +---------+---------+
                  | | Orchestration | |             :             | +---------------+
                  |             : +-------+-------+ |             | L3NM
                  |         :         |             :         |         :             |
                  |         | L3NM    |   +-------------------+   +---------+---------+
                  |         |         :         |   |       MDSC        |
                  | +---------------+ +-------+-------+ |   |      (child)      |
                  | |    Network    | |   +-------------------+   +---------+---------+
                  | | Orchestration | |             :             |
                  | +---------------+ |             :
                  +---------:---------+             :
                            :                       :
                            :             |
                  +---------+---------+             |
                            |                       |
                            | Network Configuration :
                            :                       :
               +------------:-------+     +---------:------------+ | Domain     :
                            |                       |         :
               +------------+-------+     +---------+------------+
               | Domain             |     |           Domain     |
               | Controller :         |     |         :           Controller |
               |       +---------+  |     |    +---------+       |
               |       |   PNC   |  |     |    |   PNC   |       |
               |       +---------+  |     |    +---------+       |
               +------------:-------+     +---------:------------+
                            :                       :
                            :
               +------------+-------+     +---------+------------+
                            |                       |
                            | Device Configuration  :
                            :                       :
                       +--------+              +--------+  |
                            |                       |
                       +----+---+              +----+---+
                       | Device |              | Device |
                       +--------+              +--------+

              Figure 2: L3SM and L3NM 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
   model) including future revisions of existing models (e.g., [RFC8299]
   or [RFC8466]).  The L3NM reuses these common types and groupings.

   In order to avoid data duplication and to ease passing data between
   layers when required (service layer to network layer and vice versa),
   early versions of the L3NM reused many of the data nodes that are
   defined in [RFC8299].  Nevertheless, that approach was abandoned in
   favor of the "ietf-vpn-common" module because that initial design was
   interpreted as if the deployment of L3NM depends on L3SM, while this
   is not the case.  For example, a service provider may decide to use
   the L3NM to build its L3VPN services without exposing the L3SM.

   As discussed in Section 4, the L3NM is meant to manage L3VPN 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 L3NM interfaces with other YANG modules:

   L3SM:  L3NM is not a customer service model.

      The internal view of the service (i.e., L3NM) may be mapped to an
      external view which is visible to customers: L3VPN Service YANG
      data Model (L3SM) [RFC8299].

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

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

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

   Device Modules:  L3NM is not a device model.

      Once a global VPN service is captured by means of L3NM, 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:

      *  Routing management [RFC8349].

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

      *  PIM [I-D.ietf-pim-yang].

      *  NAT management [RFC8512].

      *  QoS management [I-D.ietf-rtgwg-qos-model].

      *  ACLs [RFC8519].

      How L3NM is used to derive device-specific actions is
      implementation-specific.

6.  Sample Uses of the L3NM Data Model

   This section provides a non-exhaustive list of examples to illustrate
   contexts where the L3NM can be used.

6.1.  Enterprise Layer 3 VPN Services

   Enterprise L3VPNs are one of the most demanded services for carriers,
   and therefore, L3NM can be useful to automate the provisioning and
   maintenance of these VPNs.  Templates and batch processes can be
   built, and as a result many parameters are needed for the creation
   from scratch of a VPN that can be abstracted to the upper Software-
   Defined Networking (SDN) [RFC7149][RFC7426] layer and little manual
   intervention will be still required.

   Also

   A common function that is supported by VPNs is the addition and/or or
   removal of sites of an existing customer
   VPN sites.  Workflows can benefit of using use the L3NM by creation of workflows that either
   prune or in these
   scenarios to add or prune nodes as required from the network data mode. model as
   required.

6.2.  Multi-Domain Resource Management

   The implementation of L3VPN services which span across
   administratively separated domains (i.e., that are under the
   administration of different management systems or controllers)
   requires some network resources to be synchronized between systems.
   Particularly, there are two resources that must be orchestrated and
   manage adequately managed in each domain to
   avoid asymmetric (non-functional) configuration, or the
   usage of unavailable resources. broken configuration.

   For example, route targets (RTs) shall be synchronized between PEs.
   When all PEs are controlled by the same management system, RT
   allocation can be performed by that management system.  In cases
   where the service spans across multiple management systems, the task
   of allocating RTs has to be aligned across the domains, therefore,
   the service model must provide a way to specify RTs.  In addition,
   route distinguishers (RDs) must also be synchronized to avoid
   collisions in RD allocation between separate management systems.  An
   incorrect allocation might lead to the same RD and IP prefixes being
   exported by different PEs.

6.3.  Management of Multicast Services

   Multicast services over L3VPN can be implemented using dual PIM MVPNs
   (also known as, Draft Rosen model) [RFC4364] [RFC6037] or Multiprotocol BGP
   (MP-BGP)-based MVPNs [RFC6513][RFC6514].  Both methods are supported
   and equally effective, but the main difference is that MBGP-based
   MVPN does not require multicast configuration on the service provider
   network.  MBGP MVPNs employ the intra-autonomous system BGP control
   plane and PIM sparse mode as the data plane.  The PIM state
   information is maintained between PEs using the same architecture
   that is used for unicast VPNs.

   On the other hand, [RFC4364] [RFC6037] has limitations such as reduced options
   for transport, control plane scalability, availability, operational
   inconsistency, and the need of maintaining state in the backbone.
   Because of these limitations, MBGP MVPN is the architectural model
   that has been taken as the base for implementing multicast service in
   L3VPNs.  In this scenario, BGP auto discovery is used to discover auto-discover MVPN PE
   members and the customer PIM signaling is sent across the provider's
   core through MP-BGP.  The multicast traffic is transported on MPLS
   P2MP LSPs.

7.  Description of the L3NM YANG Module

   The L3NM ('ietf-l3vpn-ntw') is defined to manage L3VPNs in a service
   provider network.  In particular, the 'ietf-l3vpn-ntw' module can be
   used to create, modify, and retrieve L3VPN services of a network.

   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.

7.1.  Overall Structure of the Module

   The 'ietf-l3vpn-ntw' module uses two main containers: 'vpn-services'
   and 'vpn-profiles' (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 7.2).

   The 'vpn-services' container maintains the set of VPN services
   managed within the service provider network. 'vpn-service' is the
   data structure that abstracts a VPN service (Section 7.3).

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

                   Figure 3: Overall L3NM Tree Structure

7.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 scheme(s) schemes and setup that
      can be applied when building and offering a VPN service.

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

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

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

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

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

                 Figure 4: VPN Profiles Subtree Structure

7.3.  VPN Services

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

          +--rw l3vpn-ntw
             +--rw vpn-profiles
             |  ...
             +--rw vpn-services
                +--rw vpn-service* [vpn-id]
                   +--rw vpn-id                   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 status
                   |  +--rw admin-status
                   |  |  +--rw status?         identityref
                   |  |  +--rw last-updated?   yang:date-and-time
                   |  +--ro oper-status
                   |     +--ro status?         identityref
                   |     +--ro last-updated?   yang:date-and-time
                   +--rw ie-profiles vpn-instance-profiles
                   |  ...
                   +--rw underlay-transport
                   |  +-- (type)?
                   |     +--:(abstract)
                   |     |  +-- transport-instance-id?   string
                   |     +--:(protocol)
                   |       +-- protocol*           identityref
                   +--rw external-connectivity
                   |                   {external-connectivity}
                   |  +--rw (profile)?
                   |     +--:(profile)
                   |        +--rw profile-name?   leafref
                   +--rw vpn-nodes
                      ...

                 Figure 5: VPN Services Subtree Structure

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

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

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

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

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

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

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

   'vpn-type':  Indicates the VPN type.  The values are taken from
      [I-D.ietf-opsawg-vpn-common].  For the L3NM, this is typically set
      to BGP/MPLS L3VPN. L3VPN, but other values may be defined in the future
      to support specific Layer 3 VPN capabilities (e.g.,
      [I-D.ietf-bess-evpn-prefix-advertisement]).

   'vpn-service-topology':  Indicates the network topology for the
      service: hub-spoke, any-to-any, or custom.  The network
      implementation of this attribute is defined by the correct usage
      of import and export profiles (Section 4.3.5 of [RFC4364]).

   '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.

   'ie-profiles':

   'vpn-instance-profiles':  Defines reusable import/export policies parameters for the same
      'vpn-service'.

      More details are provided in Section 7.4.

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

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

   'external-connectivity':  Indicates whether/how external connectivity
      is provided to the VPN service.  For example, a service provider
      may provide an external connectivity to a VPN customer (e.g., to a
      public cloud).  Such service may involve tweaking both filtering
      and NAT rules (e.g., bind a Virtual Routing and Forwarding (VRF)
      interface with a NAT instance as discussed in Section 2.10 of
      [RFC8512]).  These added value features may be bound to all or a
      subset of network accesses.  Some of these added value features
      may be implemented in a PE or in other nodes than PEs (e.g., a P
      node or event a dedicated node that hosts the NAT function).

      Only a pointer to a local profile that defines the external
      connectivity feature is supported in this document.

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

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

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

      More details are provided in Section 7.5.

7.4.  Import/Export  VPN Instance Profiles

   The import and export

   VPN instance profiles construct contains a list with
   information related with route targets and distinguishers (RTs are meant to factorize data nodes that are used
   at many levels of the model.  Generic VPN instance profiles are
   defined at the VPN service level and
   RDs), grouped then called at the VPN node and
   VPN network access levels.  Each VPN instance profile is identified
   by 'ie-profile-id'.  The 'profile-id'.  This identifier is then referenced in for one or
   multiple 'vpn-nodes' VPN nodes (Section 7.5) so that the controller can identify
   generic resources (e.g., RTs and RDs RDs) to be configured for a given
   VRF.

   The subtree of 'ie-profiles' 'vpn-instance-profile' is shown in Figure 6.

   The following modes are supported in:

   'full-autoasigned':  The network controller auto-assigns logical
      resources (RTs, RDs).  This can apply for the deployment of new
      services.

   'rd-from-pool':  A variant of the previous one is to indicate a pool
      from where the RD values can be auto-assigned.

   'directly-assigned':  The VPN service provider (service orchestrator)
      assigns explicitly the RTs and RDs.  This case will fit with a
      brownfield scenario where some existing services need to be
      updated by the VPN service provider.

   'no-rd':  The (service orchestrator) explicitly wants no RT/RD to be
      assigned.  This case can be used for CE testing within the network
      or for troubleshooting proposes.

       +--rw l3vpn-ntw
          +--rw vpn-profiles
          |  ...
          +--rw vpn-services
             +--rw vpn-service* [vpn-id]
                +--rw vpn-id                   vpn-common:vpn-id
              +
                ...
                +--rw ie-profiles vpn-instance-profiles
                |  +--rw ie-profile* [ie-profile-id] vpn-instance-profile* [profile-id]
                |     +--rw ie-profile-id profile-id                 string
                |     +--rw role?                      identityref
                |     +--rw local-autonomous-system?   inet:as-number
                |     |      {vpn-common:rtg-bgp}?
                |     +--rw (rd-choice)?
                |     |  +--:(directly-assigned)
                |     |  |  +--rw rd?
                |     |  |         rt-types:route-distinguisher
                |     |  +--:(pool-assigned)  +--:(directly-assigned-suffix)
                |     |  |  +--rw rd-pool-name?   string rd-suffix?           uint16
                |     |  +--:(auto-assigned)
                |  +--ro rd-from-pool?     |  |  +--rw rd-auto
                |          rt-types:route-distinguisher     |  |  +--:(full-autoasigned)     +--rw (auto-mode)?
                |     |  |  +--rw auto?           empty     |  +--:(from-pool)
                |     |  +--ro rd-auto?  |     |  |          rt-types:route-distinguisher  +--rw rd-pool-name?   string
                |     |  +--:(no-rd)  |     |     +--rw no-rd?          empty  +--:(full-auto)
                |     +--rw vpn-targets     |        +--rw vpn-target* [id]  |     |     +--rw id                   int8 auto?           empty
                |     |  +--rw route-targets* [route-target]  |     +--ro auto-assigned-rd?
                |     |  +--rw route-target    rt-types:route-target  |          rt-types:route-distinguisher
                |  +--rw route-target-type     |  +--:(auto-assigned-suffix)
                |          rt-types:route-target-type     |        +--rw vpn-policies  |  +--rw import-policy?   string rd-auto-suffix
                |           +--rw export-policy?   string
              +--rw vpn-nodes
                 +--rw vpn-node* [ne-id]
                    +--rw ne-id                      string
                    ...
                    +--rw node-ie-profile?           leafref
                    ...

           Figure 6: Subtree Structure of Import/Export Profiles

7.5.  VPN Nodes

   The 'vpn-node' is an abstraction that represents a set of common
   policies applied on a given network node (typically, a PE) and belong
   to one L3VPN service.  The 'vpn-node' includes a parameter to
   indicate the network node on which it is applied.  In the case that
   the 'ne-id' points to a specific PE, the 'vpn-node' will likely be
   mapped into a VRF in the node.  However, the model also allows to
   point to an abstract node.  In this case, the network controller will
   decide how to split the 'vpn-node' into VRFs.

       +--rw l3vpn-ntw
          +--rw vpn-profiles     |  ...
          +--rw vpn-services
             +--rw vpn-service* [vpn-id]
                ...
                +--rw vpn-nodes
                   +--rw vpn-node* [vpn-node-id]
                      +--rw vpn-node-id                union
                      +--rw description?               string
                      +--rw ne-id?                     string
                      +--rw node-role?                 identityref
                      +--rw local-autonomous-system?   inet:as-number  |       {vpn-common:rtg-bgp}?
                      +--rw address-family?            identityref
                      +--rw router-id?                 inet:ip-address     +--rw (rd-choice)? (auto-mode)?
                |  +--:(directly-assigned)     |  |  +--rw rd?     |  +--:(from-pool)
                |     |          rt-types:route-distinguisher  |  +--:(pool-assigned)     |  |  +--rw rd-pool-name?        string
                |     |  +--ro rd-from-pool?  |     |          rt-types:route-distinguisher  +--:(full-auto)
                |     |  +--:(full-autoasigned)  |     |     +--rw auto?                empty
                |     |  +--ro rd-auto?  |     +--ro auto-assigned-rd-suffix?   uint16
                |          rt-types:route-distinguisher     |  +--:(no-rd)
                |     |     +--rw no-rd?               empty
                |     +--rw address-family* [address-family]
                |     |  +--rw address-family          identityref
                |     |  +--rw vpn-targets
                |     |  |  +--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          rt-types:route-target-type
                |     +--rw export-policy?   string
                      +--rw node-ie-profile?           leafref
                      +--rw maximum-routes     |  +--rw selector* [address-family protocol]  |  +--rw address-family    identityref vpn-policies
                |     +--rw protocol          identityref     |     +--rw maximum-routes?   uint32
                      +--rw groups  |     +--rw group* [group-id] import-policy?   string
                |     |  |     +--rw group-id export-policy?   string
                      +--rw multicast {vpn-common:multicast}?
                |  ...
                      +--rw status     |  +--rw admin-status maximum-routes* [protocol]
                |     |     +--rw status? protocol          identityref
                |     |     +--rw last-updated?   yang:date-and-time
                      |  +--ro oper-status
                      |     +--ro status?         identityref maximum-routes?   uint32
                |     +--ro last-updated?   yang:date-and-time     +--rw vpn-network-accesses multicast {vpn-common:multicast}?
                |        ...

           Figure 7: VPN Node 6: Subtree Structure

   In reference to the subtree shown in Figure 7, the description of VPN
   node Instance Profiles

   The description of the listed data nodes is as follows:

   'vpn-node-id':

   'profile-id':  Is an identifier that used to uniquely identifies a node that
      enable a VPN network access.

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

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

   'node-role': instance profile.

   'role':  Indicates the role of the VPN node instance profile in the VPN.  Roles
      Role values are defines defined in [I-D.ietf-opsawg-vpn-common] (e.g.,
      any-to-any-role, spoke-role, hub-role).

   'local-autonomous-system':  Indicates the BGP Autonomous System Number
      (ASN) that is configured for the VPN node.

   'address-family':  Is used to identify the address family used for
      the Router ID.  It can be set to IPv4 or IPv6.

   'router-id':  Indicates a unique Router ID information.  It can be an
      IPv4 or IPv6 address as a function of the enclosed address-family.

   'rd':  If the logical resources are managed outside the network
      controller, the model allows to explicitly indicate the logical
      resources such as RTs and RDs.  As defined in [I-D.ietf-opsawg-vpn-common] and recalled in
      Section 7.4, RDs can be explicitly configured or automatically
      assigned. [I-D.ietf-opsawg-vpn-common], these RD auto-
      assignment can also constrained by indicating
      an RD pool name ('rd- pool-name').

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

   'node-ie-profile':  Refer to Section 7.4.

   'maximum-routes':  Indicates the maximum prefixes that the VPN node
      can accept for modes are supported: direct assignment, automatic
      assignment from a given address family pool, automatic assignment, and routing protocol.  If
      'protocol' is set to 'any', this means that no
      assignment.  For illustration purposes, the maximum value
      applies to any active routing protocol.

   'groups':  Lists the groups to which a VPN node belongs to
      [I-D.ietf-opsawg-vpn-common].  The 'group-id' is following modes can be
      used to
      associate, e.g., redundancy or protection constraints with VPN
      nodes.

   'multicast':  Enables multicast traffic in the VPN.  Refer deployment cases:

      'directly-assigned':  The VPN service provider (service
         orchestrator) assigns explicitly RDs.  This case will fit with
         a brownfield scenario where some existing services need to
      Section 7.7.

   'status':  Tracks be
         updated by the status of a node involved in a VPN service.
      Both operational and administrative status are maintained.  A
      mismatch between the administrative status vs. service provider.

      'full-auto':  The network controller auto-assigns RDs.  This can
         apply for the operational
      status deployment of new services.

      'no-rd':  The VPN service provider (service orchestrator)
         explicitly wants no RD to be assigned.  This case can be used as a trigger to detect anomalies.

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

      Note that, unlike in L3SM, the L3NM does not need to model
         for CE testing within the
      customer site, only network or for troubleshooting
         proposes.

      Also, the points module accommodates deployments where only the traffic Assigned
      Number subfield of RDs (Section 4.2 of [RFC4364]) is assigned from
      a pool while the site are
      received (i.e., the PE side of PE-CE connections).  Hence, Administrator subfield is set to, e.g., the
      Router ID that is assigned to a VPN
      network access contains the connectivity information between node.  The module supports
      these modes for managing the
      provider's network Assigned Number subfield: explicit
      assignment, auto-assignment from a pool, and the customer premises.  The VPN profiles
      ('vpn-profiles') have full auto-assignment.

   'address-family':  Includes a set of routing policies that per-address family data nodes:

      'address-family':  Identifies the address family.  It can be
      applied during the service creation.

      See Section 7.6 set
         to IPv4, IPv6, or dual-stack.

      'vpn-targets':  Specifies RT import/export rules for more details.

7.6. the VPN Network Access

   The 'vpn-network-access' includes a set
         service (Section 4.3 of data nodes [RFC4364]).

      'maximum-routes':  Indicates the maximum prefixes that describe the access information VPN
         node can accept for a given routing protocol.  If 'protocol' is
         set to 'any', this means that the maximum value applies to each
         active routing protocol.

   'multicast':  Enables multicast traffic that belongs in the VPN service.  Refer to
      Section 7.7.

7.5.  VPN Nodes

   The 'vpn-node' is an abstraction that represents a particular set of common
   policies applied on a given network node (typically, a PE) and belong
   to one L3VPN (Figure 8).

   ... service.  The 'vpn-node' includes a parameter to
   indicate the network node on which it is applied.  In the case that
   the 'ne-id' points to a specific PE, the 'vpn-node' will likely be
   mapped into a VRF in the node.  However, the model also allows to
   point to an abstract node.  In this case, the network controller will
   decide how to split the 'vpn-node' into VRFs.

    +--rw vpn-nodes l3vpn-ntw
       +--rw vpn-node* [vpn-node-id] vpn-profiles
       |  ...
       +--rw vpn-network-accesses vpn-services
          +--rw vpn-network-access* [id] vpn-service* [vpn-id]
             ...
             +--rw id                         vpn-common:vpn-id vpn-nodes
                +--rw port-id? vpn-node* [vpn-node-id]
                   +--rw vpn-node-id                vpn-common:vpn-id
                   +--rw description?               string
                   +--rw vpn-network-access-type?   identityref ne-id?                     string
                   +--rw status local-autonomous-system?   inet:as-number
                   |       {vpn-common:rtg-bgp}?
                   +--rw admin-status router-id?                 rt-types:router-id
                   +--rw active-vpn-instance-profiles
                   |  +--rw vpn-instance-profile* [profile-id]
                   |     +--rw status? profile-id                 leafref
                   |     +--rw router-id* [address-family]
                   |     |  +--rw address-family    identityref
                   |     |  +--rw last-updated?   yang:date-and-time router-id?        inet:ip-address
                   |  +--ro oper-status     +--rw local-autonomous-system?   inet:as-number
                   |     +--ro status?         identityref     |     +--ro last-updated?   yang:date-and-time     {vpn-common:rtg-bgp}?
                   |     +--rw connection (rd-choice)?
                   |     |  ....
                   |  ...     +--rw ip-connection address-family* [address-family]
                   |     |  ...  +--rw routing-protocols address-family          identityref
                   |     |  |  ...
                   |     |  +--rw oam vpn-targets
                   |     |  |  ...
                   |     |  +--rw security maximum-routes* [protocol]
                   |     |     ...
                   |     +--rw service multicast {vpn-common:multicast}?
                   |        ...
                   +--rw msdp {msdp}?
                   |  +--rw peer?            inet:ip-address
                   |  +--rw local-address?   inet:ip-address
                   |  +--rw status
                   |     +--rw admin-status
                   |     |  +--rw status?         identityref
                   |     |  +--rw last-updated?   yang:date-and-time
                   |     +--ro oper-status
                   |        +--ro status?         identityref
                   |        +--ro last-updated?   yang:date-and-time
                   +--rw groups
                   |  +--rw group* [group-id]
                   |     +--rw group-id    string
                   +--rw status
                   |  +--rw admin-status
                   |  |  +--rw status?         identityref
                   |  |  +--rw last-updated?   yang:date-and-time
                   |  +--ro oper-status
                   |     +--ro status?         identityref
                   |     +--ro last-updated?   yang:date-and-time
                   +--rw vpn-network-accesses
                      ...

                   Figure 8: 7: VPN Network Access Node Subtree Structure

   In reference to the subtree depicted shown in Figure 8, a 'vpn-network-
   access' includes 7, the following description of VPN
   node data nodes:

   'id': nodes is as follows:

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

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

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

   'vpn-network-access-type':  Is used to select the type node.

   'ne-id':  Includes a unique identifier of the network
      interface to be deployed in element where
      the devices.  The available options
      are:

      Point-to-Point:  Represents a direct connection between VPN node is deployed.

   'local-autonomous-system':  Indicates the end-
         points.  It implies ASN that is configured for
      the controller must keep the
         association between VPN node.

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

   'active-vpn-instance-profiles':  Lists the set of active VPN instance
      profiles for this VPN node.  Concretely, one or physical interface on more VPN instance
      profiles that are defined at the
         device with VPN service level can be enabled
      at the 'id' VPN node level; each of these profiles is uniquely
      identified by means of 'profile-id'.  The structure of 'active-
      vpn-instance-profiles' is the 'vpn-network-access'.

      Multipoint:  Represents a broadcast connection between same as the end-
         points.  It implies that the controller must keep the
         association between a logical or physical interface on the
         device with the 'id' of the 'vpn-network-access'.

      Pseudowire:  Represents a connection coming from an L2VPN service.
         It implies that the controller must keep the relationship
         between the logical tunnels or bridges on the devices one discussed in
      Section 7.4 with the
         'id' of the' vpn-network-access'.

      Loopback:  Represents the creation exception of a logical interface on a
         device.  An example to illustrate how loopback interfaces 'router-id'.  Indeed, Router IDs
      can be created configured per address family.  This capability can be
      used, for example, to configure an IPv6 address as a Router ID
      when such capability is provided supported by involved routers.

      Values defined in Figure 35.

   'status':  Indicates both operational and administrative status of a 'active-vpn-instance-profiles' overrides the
      ones defined in the VPN network access.

   'connection':  Represents service level.

   'msdp':  For redundancy purposes, Multicast Source Discovery Protocol
      (MSDP) [RFC3618] may be enabled and groups used to share the set state about
      sources between multiple rendez-vous points (RPs).  The purpose of Layer 2 connectivity
      from where
      MSDP in this context is to enhance the traffic robustness of the L3VPN multicast
      service.  MSDP may be configured on non-RP routers, which is
      useful in a particular VPN Network
      access is coming.  See Section 7.6.1.

   'ip-connection':  Contains domain that does not support multicast sources, but
      does support multicast transit.

   'groups':  Lists the IP addressing information of groups to which a VPN
      network access.  See Section 7.6.2.

   'routing-protocols':  Represents and groups the set of Layer 2
      connectivity from where node belongs to
      [I-D.ietf-opsawg-vpn-common].  The 'group-id' is used to
      associate, e.g., redundancy or protection constraints with VPN
      nodes.

   'status':  Tracks the traffic status of the L3VPN a node involved in a particular VPN Network access is coming.  See Section 7.6.3.

   'oam':  Specifies the Operations, Administration, service.
      Both operational and Maintenance
      (OAM) mechanisms used for a VPN network accesss.  See
      Section 7.6.4.

   'security':  Specifies administrative status are maintained.  A
      mismatch between the authentication and administrative status vs. the encryption to operational
      status can be
      applied for used as a given VPN network access.  See Section 7.6.5.

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

7.6.1.  Connection

   The definition of a L3VPN is commonly specified not only at detect anomalies.

   'vpn-network-accesses':  Represents the IP
   layer, but also requires point to provide parameters at which sites are
      connected.

      Note that, unlike in L3SM, the Ethernet layer,
   such as specifying an encapsulation type (e.g., VLAN, QinQ, QinAny,
   VxLAN, etc.).  The L3NM uses the 'connection' container does not need to specify
   such parameters.

   A model the
      customer site, as per [RFC4176] represents a VPN customer's location that is
   connected to only the service provider network via a CE-PE link, which can
   access at least one VPN.  The connection points where the traffic from the site to the service
   provider network is are
      received (i.e., the bearer.  Every site is associated with a list PE side of bearers.  A bearer is the layer two connections with the site.  In
   the L3NM, it is assumed that PE-CE connections).  Hence, the bearer has been allocated by VPN
      network access contains the
   service provider at connectivity information between the service orchestration stage.  The bearer is
   associated to a
      provider's network element and a port.  Hence, a bearer is just
   a bearer-reference to allow the translation between customer premises.  The VPN profiles
      ('vpn-profiles') have a set of routing policies that can be
      applied during the service request
   (e.g., L3SM) and L3NM.

   As shown in Figure 9, creation.

      See Section 7.6 for more details.

7.6.  VPN Network Access

   The 'vpn-network-access' includes a set of data nodes that describe
   the 'connection' container defines protocols
   and parameters access information for the traffic that belongs to enable connectivity at Layer 2. a particular
   L3VPN (Figure 8).

   ...
   +--rw connection
             |  +--rw encapsulation-type?   identityref
             |  +--rw logical-interface
             |  |  +--rw peer-reference?   uint32
             |  +--rw tagged-interface
             |  |  +--rw type?                identityref
             |  | vpn-nodes
      +--rw dot1q-vlan-tagged {vpn-common:dot1q}?
             |  |  | vpn-node* [vpn-node-id]
         ...
         +--rw tag-type?   identityref
             |  |  | vpn-network-accesses
            +--rw cvlan-id?   uint16
             |  | vpn-network-access* [id]
               +--rw priority-tagged
             |  |  | id                         vpn-common:vpn-id
               +--rw tag-type?   identityref
             |  | port-id?                   vpn-common:vpn-id
               +--rw qinq {vpn-common:qinq}?
             |  |  | description?               string
               +--rw tag-type? vpn-network-access-type?   identityref
             |  |  |
               +--rw svlan-id    uint16
             |  |  | vpn-instance-profile?      leafref
               +--rw cvlan-id    uint16
             | status
               |  +--rw qinany {vpn-common:qinany}?
             | admin-status
               |  |  +--rw tag-type? status?         identityref
               |  |  |  +--rw svlan-id    uint16
             |  |  +--rw vxlan {vpn-common:vxlan}?
             |  |  +--rw vni-id       uint32 last-updated?   yang:date-and-time
               |  +--ro oper-status
               |     +--rw peer-mode?     +--ro status?         identityref
               |  |     +--rw peer-list* [peer-ip]
             |  |        +--rw peer-ip    inet:ip-address
             |  +--rw bearer
             |     +--rw bearer-reference?   string
             |     |       {vpn-common:bearer-reference}?
             |     +--ro last-updated?   yang:date-and-time
               +--rw pseudowire
             | connection
               |  ...
               +--rw vcid?      uint32
             | ip-connection
               |  ...
               +--rw far-end?   union routing-protocols
               |  ...
               +--rw vpls oam
               |  ...
               +--rw vcid?      union security
               |  ...
               +--rw far-end?   union service
                  ...

              Figure 9: Connection 8: VPN Network Access Subtree Structure

7.6.2.  IP Connections

   This container is used

   In reference to group the IP addressing information of subtree depicted in Figure 8, a 'vpn-network-
   access' includes the following data nodes:

   'id':  Is an identifier of the VPN network access.  The allocated address represents

   'port-id':  Indicates the PE
   interface address configuration.  As shown in Figure 10, this
   container can include IPv4, IPv6, or both information if dual-stack
   is enabled.

                  ...
                  +--rw vpn-network-accesses
                     +--rw vpn-network-access* [id]
                        ...
                        +--rw ip-connection
                        |  +--rw ipv4 {vpn-common:ipv4}?
                        |  |  ...
                        |  +--rw ipv6 {vpn-common:ipv6}?
                        |     ...
                        ...

                Figure 10: IP Connection Subtree Structure

   For both IPv4 and IPv6, port on which the IP connection supports three IP address
   assignment modes for customer addresses: provider DHCP, DHCP relay,
   and static addressing.  Only one mode VPN network access is enabled for
      bound.

   'description':  Includes a given service.
   Note that for textual description of the IPv6 cases, SLAAC [RFC7527] can be used.

   Figure 11 shows VPN network
      access.

   'vpn-network-access-type':  Is used to select the structure type of network
      interface to be deployed in the dynamic IPv4 address assignment.

   ...
   +--rw ip-connection
   |  +--rw ipv4 {vpn-common:ipv4}?
   |  |  +--rw local-address?                           inet:ipv4-prefix
   |  |  +--rw address-allocation-type?                 identityref
   |  |  +--rw (allocation-type)?
   |  |     +--:(provider-dhcp)
   |  |     |  +--rw dhcp-server-enable?                boolean
   |  |     |  +--rw (address-assign)?
   |  |     |     +--:(number)
   |  |     |     |  +--rw number-of-dynamic-address?   uint16
   |  |     |     +--:(explicit)
   |  |     |        +--rw customer-addresses
   |  |     |           +--rw address-group* [group-id]
   |  |     |              +--rw group-id         string
   |  |     |              +--rw start-address?   inet:ipv4-address
   |  |     |              +--rw end-address?     inet:ipv4-address
   |  |     +--:(dhcp-relay)
   |  |     |  +--rw dhcp-relay-enable?                 boolean
   |  |     |  +--rw customer-dhcp-servers
   |  |     |     +--rw server-ip-address*   inet:ipv4-address
   |  |     +--:(static-addresses)
   |  |        ...
   ...

             Figure 11: IP Connection Subtree Structure (IPv4)

   Figure 12 shows devices.  The available defined
      values are:

      'point-to-point':  Represents a direct connection between the structure
         endpoints.  The controller must keep the association between a
         logical or physical interface on the device with the 'id' of
         the dynamic IPv6 address assignment.

   ...
   +--rw ip-connection
   |  +--rw ipv4 {vpn-common:ipv4}?
   |  |  ...
   |  +--rw ipv6 {vpn-common:ipv6}?
   |     +--rw local-address?                           inet:ipv6-prefix
   |     +--rw address-allocation-type?                 identityref
   |     +--rw (allocation-type)?
   |        +--:(provider-dhcp)
   |        |  +--rw dhcp-server-enable?                boolean
   |        |  +--rw (address-assign)?
   |        |     +--:(number)
   |        |     |  +--rw number-of-dynamic-address?   uint16
   |        |     +--:(explicit)
   |        |        +--rw customer-addresses
   |        |           +--rw address-group* [group-id]
   |        |              +--rw group-id         string
   |        |              +--rw start-address?   inet:ipv6-address
   |        |              +--rw end-address?     inet:ipv6-address
   |        +--:(dhcp-relay)
   |        |  +--rw dhcp-relay-enable?                 boolean
   |        |  +--rw customer-dhcp-servers
   |        |     +--rw server-ip-address*   inet:ipv6-address
   |        +--:(static-addresses)
   |           ...
   ...

             Figure 12: IP Connection Subtree Structure (IPv6)

   In 'vpn-network-access'.

      'multipoint':  Represents a broadcast connection between the case of
         endpoints.  The controller must keep the static addressing (Figure 13), association between a
         logical or physical interface on the model supports device with the assignment 'id' of several IP addresses
         the 'vpn-network-access'.

      'irb':  Represents a connection coming from an L2VPN service.  An
         identifier of such service ('l2vpn-id') may be included in the same 'vpn-network-
         'connection' container as depicted in Figure 9.  The controller
         must keep the relationship between the logical tunnels or
         bridges on the devices with the 'id' of the' vpn-network-
         access'.  To identify which

      'loopback':  Represents the creation of a logical interface on a
         device.  An example to illustrate how a loopback interface can
         be used in the addresses L3NM is provided in Appendix A.2.

   'vpn-instance-profile':  Provides a pointer to an active VPN instance
      profile at the primary address VPN node level.  Referencing an active VPN instance
      profile implies that all associated data nodes will be inherited
      by the VPN network access.  However, some of a connection ,the 'primary-address' reference MUST the inherited data
      nodes (e.g., multicast) can be set with refined at the
   corresponding 'address-id'.

   ...
   +--rw ip-connection
   |  +--rw ipv4 {vpn-common:ipv4}?
   |  |  +--rw address-allocation-type?         identityref
   |  |  +--rw (allocation-type)?
   |  |     ...
   |  |     +--:(static-addresses)
   |  |        +--rw primary-address?        -> ../address/address-id
   |  |        +--rw address* [address-id]
   |  |           +--rw address-id              string
   |  |           +--rw customer-address?     inet:ipv4-address
   |  +--rw ipv6 {vpn-common:ipv6}?
   |     +--rw address-allocation-type?         identityref
   |     +--rw (allocation-type)?
   |        ...
   |        +--:(static-addresses)
   |           +--rw primary-address?     -> ../address/prefix-id
   |           +--rw address* [address-id]
   |              +--rw prefix-id              string
   |              +--rw customer-prefix?     inet:ipv6-prefix
   ...

         Figure 13: IP Connection Subtree Structure (Static Mode)

7.6.3.  CE-PE Routing Protocols

   A VPN service provider can configure one or more routing protocols
   associated with network access
      level.  In such case, refined values take precedence over
      inherited ones.

   'status':  Indicates both operational and administrative status of a
      VPN network access.

   'connection':  Represents and groups the set of Layer 2 connectivity
      from where the traffic of the L3VPN in a particular 'vpn-network-access'.  Such routing
   protocol VPN Network
      access is enabled between coming.  See Section 7.6.1.

   'ip-connection':  Contains Layer 3 connectivity information of a VPN
      network access (e.g., IP addressing).  See Section 7.6.2.

   'routing-protocols':  Includes the PE CE-PE rouing configuration
      information.  See Section 7.6.3.

   'oam':  Specifies the Operations, Administration, and Maintenance
      (OAM) mechanisms used for a VPN network access.  See
      Section 7.6.4.

   'security':  Specifies the CE.  Each instance is
   uniquely identified to accommodate scenarios where multiple instances
   of authentication and the same routing protocol have encryption to be configured on
      applied for a given VPN network access.  See Section 7.6.5.

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

7.6.1.  Connection

   The subtree of 'connection' container represents the 'routing-protocols' is shown in Figure 14.

              ...
              +--rw vpn-network-accesses
                 +--rw vpn-network-access* [id]
                    ...
                    +--rw routing-protocols
                    |  +--rw routing-protocol* [id]
                    |     +--rw id   string
                    |     +--rw type?               identityref
                    |     +--rw routing-profiles* [id]
                    |     |  +--rw id      leafref
                    |     |  +--rw type?   identityref
                    |     +--rw static
                    |     |  ...
                    |     +--rw bgp {vpn-common:rtg-bgp}?
                    |     |  ...
                    |     +--rw ospf {vpn-common:rtg-ospf}?
                    |     |  ...
                    |     +--rw isis {vpn-common:rtg-isis}?
                    |     |  ...
                    |     +--rw rip {vpn-common:rtg-rip}?
                    |     |  ...
                    |     +--rw vrrp {vpn-common:rtg-vrrp}?
                    |        ...
                    +--rw security
                        ... layer 2 connectivity to the
   L3VPN for a particular VPN network access.  As shown in the tree
   depicted in Figure 14: Routing Subtree Structure

   Multiple routing instances 9, the 'connection' container defines protocols
   and parameters to enable such connectivity at layer 2.

   The traffic can be defined; each uniquely identified
   by an 'id'. enter the VPN with or without encapsulation (e.g.,
   VLAN, QinQ).  The type of a routing instance is indicated in 'type'. 'encapsulation' container specifies the layer 2
   encapsulation to use (if any) and allows to configure the relevant
   tags.

   The values of this attributes are those defined in
   [I-D.ietf-opsawg-vpn-common] ('routing-protocol-type' identity).

   Configuring multiple instances of interface that is attached to the same routing protocol does not
   automatically imply that, from L3VPN is identified by the
   'port-id' at the 'vpn-network-access' level.  From a device configuration network model
   perspective,
   there will be parallel instances (e.g., multiple processes) running
   on it is expected that the PE-CE link.  It 'port-id' is up to each implementation sufficient to decide about
   identify the appropriate configuration as a function of underlying
   capabilities and service provider operational guidelines.  As an
   example, when multiple BGP peers need interface.  However, specific layer 2 sub-interfaces may
   be required to be implemented, multiple
   instances of BGP must be configured as part of this model.  However,
   from a device configuration point of view, this could be implemented
   as:

   o  Multiple BGP processes with a single neighbor running in each
      process.

   o  A single BGP process with multiple neighbors running.

   o  A combination thereof.

   Routing configuration does not include low-level policies. some implementations/deployments.
   Such
   policies are handed at the device configuration level.  Local
   policies of a service provider (e.g., filtering) will layer 2 specific interface can be implemented
   as part of the device configuration; these are not captured included in the
   L3NM, but the model allows 'l2-termination-
   point'.

   If a layer 2 tunnel is needed to associate local profiles with routing
   instances ('routing-profiles').

   The L3NM supports terminate the configuration of one or more IPv4/IPv6 static
   routes.  Since service in the same structure CE-PE
   connection, the 'l2-tunnel-service' container is used for both IPv4 and IPv6, it
   was considered to have one single container specify the
   required parameters to group both static
   entries independently of their address family, but set such tunneling service (e.g., VPLS,
   VXLAN).  An identity, called 'l2-tunnel-type', is defined for layer 2
   tunnel selection.

   To accommodate implementations that design was
   abandoned to ease the mapping with the structure in [RFC8299].  As
   depicted in Figure 15, the following data nodes require internal bridging, a
   local bridge reference can be defined for specified in 'local-bridge-reference'.
   Such a
   given IP prefix:

   'lan-tag':  Indicates reference may be a local tag (e.g., "myfavourite-lan") that bridge domain.

   As discussed in Section 7.6, 'l2vpn-id' is used to enforce local policies.

   'next-hop':  Indicates identify the next-hop L2VPN
   service that is associated with an IRB interface.

   A site, as per [RFC4176] represents a VPN customer's location that is
   connected to be used for the static route.
      It can be identified by an IP address, an interface, etc.

   'bfd-enable':  Indicates whether BFD service provider network via a CE-PE link, which can
   access at least one VPN.  The connection from the site to the service
   provider network is enabled or disabled for this
      static route entry.

   'metric':  Indicates the metric bearer.  Every site is associated with a list
   of bearers.  A bearer is the static route
      entry.

   'preference':  Indicates the preference associated layer two connections with the static
      route entry.  This preference site.  In
   the L3NM, it is used to selecting a preferred
      route among routes to assumed that the same destination prefix.

   'status':  Used to convey bearer has been allocated by the status of
   service provider at the service orchestration stage.  The bearer is
   associated to a static route entry.  This
      data node network element and a port.  Hence, a bearer is used just
   a 'bearer-reference' to control allow the (de)activation of individual
      static route entries. association between a service
   request (e.g., L3SM) and L3NM.

           ...
           +--rw routing-protocols
       |  +--rw routing-protocol* [id]
       |     ... connection
           |  +--rw static encapsulation
           |  |  +--rw cascaded-lan-prefixes type?              identityref
           |  |  +--rw ipv4-lan-prefixes*
       |     |     |       [lan next-hop]
       |     |     |       {vpn-common:ipv4}? dot1q {vpn-common:dot1q}?
           |  |  |  +--rw lan         inet:ipv4-prefix tag-type?   identityref
           |  |  |  +--rw lan-tag?      string
       | cvlan-id?   uint16
           |  |  +--rw next-hop      union priority-tagged
           |  |  |  +--rw bfd-enable?   boolean
       | tag-type?   identityref
           |  |  +--rw metric?       uint32
       | qinq {vpn-common:qinq}?
           |  |     +--rw preference?   uint32
       | tag-type?   identityref
           |  |     +--rw status
       | svlan-id    uint16
           |  |     +--rw admin-status
       | cvlan-id    uint16
           |  +--rw l2-tunnel-service
           |  |  +--rw status? type?         identityref
           |  |     |     |  +--rw last-updated?   yang:date-and-time pseudowire
           |  |  |     +--ro oper-status  +--rw vcid?      uint32
           |  |  |        +--ro status?         identityref  +--rw far-end?   union
           |  |  +--rw vpls
           |        +--ro last-updated?   yang:date-and-time  |  |  +--rw ipv6-lan-prefixes*
       | vcid?      union
           |             [lan next-hop]  |  |             {vpn-common:ipv6}?  +--rw far-end?   union
           |  |  +--rw lan         inet:ipv6-prefix vxlan {vpn-common:vxlan}?
           |  |     +--rw lan-tag?      string vni-id             uint32
           |  |     +--rw next-hop      union peer-mode?         identityref
           |  |     +--rw bfd-enable?   boolean
       | peer-ip-address*   inet:ip-address
           |  +--rw metric?       uint32
       |     |        +--rw preference?   uint32
       |     |        +--rw status
       | l2-termination-point?     vpn-common:vpn-id
           |  +--rw admin-status
       |     | local-bridge-reference?   vpn-common:vpn-id
           |  +--rw status?         identityref
       |     | l2vpn-id?                 vpn-common:vpn-id
           |  +--rw last-updated?   yang:date-and-time
       |     |           +--ro oper-status
       |     |              +--ro status?         identityref
       |     |              +--ro last-updated?   yang:date-and-time bearer-reference?         string
                      {vpn-common:bearer-reference}?
           ...

                  Figure 15: Static Routing 9: Connection Subtree Structure

   In addition, the L3NM supports the following CE-PE routing protocols:

   BGP:  The L3NM allows to configure a BGP neighbor, including a set
      for parameters that are pertinent to be tweaked at the network
      level for service customization purposes.

7.6.2.  IP Connection

   This container does not aim to include every BGP parameter; a
      comprehensive set of parameters belongs more to the BGP device
      model.

      The following data nodes are captured in Figure 16.  It is up used to group Layer 3 connectivity information,
   particularly the implementation to derive IP addressing information, of a VPN network access.
   The allocated address represents the corresponding BGP device
      configuration:

      'description':  Includes PE interface address
   configuration.  Note that a description of distinct layer 3 interface than the BGP session.

      'local-autonomous-system':  Is set to one
   indicated under the AS Number (ASN) 'connection' container may be needed to
         override a customer ASN if terminate
   the layer 3 service.  The identifier of such feature interface is requested by the
         customer.

      'peer-autonomous-system':  Conveys the customer's ASN.

      'address-family':  Indicates included in
   'l3-termination-point'.  For example, this data node can be used to
   carry the address-family identifier of a bridge domain Interface.

   As shown in Figure 10, the peer.  It 'ip-connection' container can be set to include
   IPv4, IPv6, or dual-stack.

      'neighbor':  Can indicate two neighbors (each for a given address-
         family) or one neighbor (if 'address-family' attribute both if dual-stack is set
         to dual-stack).  A list of IP address(es) of the BGP neighbors
         can be then conveyed in this data node.

      'multihop':  Indicates the number of allowed enabled.

        ...
        +--rw vpn-network-accesses
           +--rw vpn-network-access* [id]
              ...
              +--rw ip-connection
              |  +--rw l3-termination-point?     vpn-common:vpn-id
              |  +--rw ipv4 {vpn-common:ipv4}?
              |  |  ...
              |  +--rw ipv6 {vpn-common:ipv6}?
              |     ...
              ...

                Figure 10: IP hops between a PE Connection Subtree Structure

   For both IPv4 and its BGP peer.

      'as-override':  If set, this parameter indicates whether ASN
         override is enabled, i.e., replace the ASN of IPv6, the IP connection supports three IP address
   assignment modes for customer
         specified in the AS_PATH BGP attribute with the ASN identified
         in addresses: provider DHCP, DHCP relay,
   and static addressing.  Note that for the 'local-autonomous-system' attribute.

      'default-route':  Controls whether default route(s) IPv6 case, SLAAC [RFC4862]
   can be
         advertised to the peer.

      'site-of-origin':  Is meant to uniquely identify the set of routes
         learned from a site via a particular CE/PE connection used.  For both IPv4 and is
         used to prevent routing loops (Section 7 of [RFC4364]).  The
         Site of Origin attribute is encoded as a Route Origin Extended
         Community.

      'ipv6-site-of-origin':  Carries an IPv6 Address Specific BGP
         Extended that IPv6, 'address-allocation-type' is
   used to indicate the Site of Origin IP address allocation mode to activate for VRF
         information [RFC5701].  It a
   given VPN network access.

   When 'address-allocation-type' is used set to prevent routing loops.

      'bgp-max-prefix':  Controls the 'provider-dhcp', DHCP
   assignments can be made locally or by an external DHCP server.  Such
   as behavior when a prefix maximum is
         reached.

         'max-prefix':  Indicates controlled by setting 'dhcp-service-type'.

   Figure 11 shows the maximum number structure of BGP prefixes
            allowed in the BGP session.  If such limit is reached, the
            action indicated in 'action-violate' will be followed.

         'warning-threshold':a warning
         notification will be triggered'
      A warning notification is triggered when this limit is reached.

   'violate-action':  Indicates which action to execute when the maximum
      number of BGP prefixes is reached.  Examples of such actions are:
      send a warning message, discard extra paths from the peer, or
      restart the session.

      'bgp-timers':   Two timers can be captured in this container: (1)
         'hold-time' which is the time interval that will be used for
         the HoldTimer (Section 4.2 of [RFC4271]) when establishing a
         BGP session.  (2) 'keep-alive' which is the time interval for
         the KeepAlive timer between a PE and a BGP peer (Section 4.4 of
         [RFC4271]).

      'security':  The module adheres to the recommendations in
         Section 13.2 of [RFC4364] as it allows to enable TCP-AO
         [RFC5925] and accommodates the installed base that make use of
         MD5.  In addition, the module includes a provision for the use
         of IPsec.

      'status':  Indicates the status dynamic IPv4 address assignment
   (i.e., by means of the BGP routing instance. DHCP).

        ...
        +--rw routing-protocols
  |  +--rw routing-protocol* [id]
  |     ... ip-connection
        |  +--rw bgp {vpn-common:rtg-bgp}?
  | l3-termination-point?     vpn-common:vpn-id
        |  +--rw description?               string ipv4 {vpn-common:ipv4}?
        |  |  +--rw local-autonomous-system?   inet:as-number local-address?             inet:ipv4-address
        |  |  +--rw peer-autonomous-system     inet:as-number prefix-length?             uint8
        |  |  +--rw address-family? address-allocation-type?   identityref
        |  |  +--rw neighbor*                  inet:ip-address
  | (allocation-type)?
        |  +--rw multihop?                  uint8  |     +--:(provider-dhcp)
        |  +--rw as-override?               boolean  |     |  +--rw default-route?             boolean dhcp-service-type?   enumeration
        |  |     |  +--rw site-of-origin?            rt-types:route-origin (service-type)?
        |  |  +--rw ipv6-site-of-origin?       rt-types:ipv6-route-origin     |     +--:(relay)
        |  +--rw bgp-max-prefix  |     |     |  +--rw max-prefix?          uint32
  | server-ip-address*
        |  |  +--rw warning-threshold?   decimal64     |     |          inet:ipv4-address
        |  +--rw violate-action?      enumeration  |     |     +--:(server)
        |  +--rw restart-interval?    uint16  |     |        +--rw bgp-timers
  | (address-assign)?
        |  |  +--rw keep-alive?   uint16     |           +--:(number)
        |  |  +--rw hold-time?    uint16     |           |  +--rw security number-of-dynamic-address?
        |  |     |  +--rw enable?            boolean           |           uint16
        |  |  +--rw keying-material     |           +--:(explicit)
        |  |     +--rw (option)?     |              +--rw customer-addresses
        |  |        +--:(tcp-ao)     |                 +--rw address-pool* [pool-id]
        |  |     |                    +--rw enable-tcp-ao?      boolean
  | pool-id          string
        |  |     |                    +--rw ao-keychain?        key-chain:key-chain-ref start-address?
        |  |     |        +--:(md5)                    |           inet:ipv4-address
        |  |     |                    +--rw md5-keychain?   key-chain:key-chain-ref end-address?
        |  |     |        +--:(explicit)                                inet:ipv4-address
        |  |     +--:(dhcp-relay)
        |  |  +--rw key-id?             uint32     |  +--rw customer-dhcp-servers
        |  |     |     +--rw key?                string server-ip-address*   inet:ipv4-address
        |  |     +--:(static-addresses)
        |  |        ...
        ...

             Figure 11: IP Connection Subtree Structure (IPv4)

   Figure 12 shows the structure of the dynamic IPv6 address assignment
   (i.e., DHCPv6 and/or SLAAC).  Note that if 'address-allocation-type'
   is set to 'slaac', the Prefix Information option of Router
   Advertisements that will be issued for SLAAC purposes, will carry the
   IPv6 prefix that is determined by 'local-address' and 'prefix-
   length'.  For example, if 'local-address' is set to '2001:db8:0:1::1'
   and 'prefix-length' is set to '64', the IPv6 prefix that will be used
   is '2001:db8:0:1::/64'.

       ...
       +--rw ip-connection
       |  +--rw l3-termination-point?     vpn-common:vpn-id
       |  +--rw ipv4 {vpn-common:ipv4}?
       |  |  ...
       |  +--rw crypto-algorithm? ipv6 {vpn-common:ipv6}?
       |     +--rw local-address?                 inet:ipv6-address
       |     +--rw prefix-length?                 uint8
       |     +--rw address-allocation-type?       identityref
       |     +--rw (allocation-type)?
       |     |        +--:(ipsec)  +--rw provider-dhcp
       |     |     +--rw dhcp-service-type?         enumeration
       |     |     +--rw sa?             string (service-type)?
       |     |        +--:(provider-dhcp-servers)
       |     |        |  +--rw status server-ip-address*
       |     |        |                       inet:ipv6-address
       |     |        +--:(server)
       |     |           +--rw admin-status (address-assign)?
       |     |              +--:(number)
       |     |              |  +--rw status?         identityref number-of-dynamic-address?
       |     |              |                            uint16
       |     |              +--:(explicit)
       |     |                +--rw last-updated?   yang:date-and-time customer-addresses
       |     |     +--ro oper-status                    +--rw address-pool* [pool-id]
       |     |        +--ro status?         identityref                       +--rw pool-id       string
       |     |        +--ro last-updated?   yang:date-and-time                       +--rw start-address?
       |     |                       |        inet:ipv6-address
       |     |                       +--rw end-address?
       |     |                                 inet:ipv6-address
       |     +--:(dhcp-relay)
       |        |  +--rw customer-dhcp-servers
       |        |     +--rw server-ip-address*   inet:ipv6-address
       |        +--:(static-addresses)
       |           ...
       ...

             Figure 16: BGP Routing 12: IP Connection Subtree Structure

   OSPF:  OSPF can be configured to run as a routing protocol on (IPv6)

   In the
      'vpn-network-access' [RFC4577][RFC6565].  The following data nodes
      are captured case of the static addressing (Figure 13), the model supports
   the assignment of several IP addresses in Figure 17:

      'address-family':  Indicates whether IPv4, IPv6, or both address
         families are to be activated.

         When only the IPv4 address-family same 'vpn-network-
   access'.  To identify which of the addresses is requested, it will be up
         to the implementation to decide whether OSPFv2 [RFC2328] or
         OSPFv3 [RFC5340] is used.

      'area-id':  Indicates the OSPF Area ID.

      'metric':  Associates a metric with OSPF routes.

      'sham-links':  Is used to create OSPF sham links between two VPN
         network accesses sharing the same area and having a backdoor
         link (Section 4.2.7 of [RFC4577]).

      'max-lsa':  Sets the maximum number primary address
   of LSAs that the OSPF instance
         will accept.

      'security':  Controls the authentication schemes to a connection ,the 'primary-address' reference MUST be enabled for
         the OSPF instance.  The following options are supported: IPsec
         for OSPFv3 authentication [RFC4552], authentication trailer for
         OSPFv2 [RFC5709] [RFC7474] and OSPFv3 [RFC7166].

      'status':  Indicates the status of set with the OSPF routing instance.
   corresponding 'address-id'.

    ...
    +--rw routing-protocols ip-connection
    |  +--rw routing-protocol* [id]
        |     ... l3-termination-point?     vpn-common:vpn-id
    |  +--rw ospf {vpn-common:rtg-ospf}? ipv4 {vpn-common:ipv4}?
    |  |  +--rw address-family? address-allocation-type?         identityref
    |  |  +--rw area-id           yang:dotted-quad
        | (allocation-type)?
    |  +--rw metric?           uint16  |     ...
    |  +--rw sham-links  {vpn-common:rtg-ospf-sham-link}?  |     +--:(static-addresses)
    |  |        +--rw sham-link* [target-site]
        | primary-address?        -> ../address/address-id
    |  |        +--rw target-site
        |     |  |     |       vpn-common:vpn-id
        | address* [address-id]
    |  |           +--rw metric?        uint16 address-id          string
    |  |           +--rw max-lsa?          uint32
        | customer-address?   inet:ipv4-address
    |  +--rw security
        |     | ipv6 {vpn-common:ipv6}?
    |     +--rw enable?            boolean
        |     | address-allocation-type?         identityref
    |     +--rw keying-material (allocation-type)?
    |        ...
    |        +--:(static-addresses)
    |           +--rw (option)?
        |     |  |        +--:(md5)
        |     |  | primary-address?     -> ../address/address-id
    |           +--rw md5-keychain?
        |     |  |        |          kc:key-chain-ref
        |     |  |        +--:(ipsec)
        |     | address* [address-id]
    |              +--rw sa? address-id              string
    |     |  +--rw status
        |     |     +--rw admin-status
        |     |     |              +--rw status?        identityref
        |     |     |  +--rw last-updated?  yang:date-and-time
        |     |     +--ro oper-status
        |     |        +--ro status?        identityref
        |     |        +--ro last-updated?  yang:date-and-time customer-address?     inet:ipv6-address
    ...

         Figure 17: OPSF Routing 13: IP Connection Subtree Structure

   IS-IS:  The model (Figure 18) allows the user to configure IS-IS to
      run on the 'vpn-network-access' interface.  The following IS-IS
      data nodes are supported:

      'address-family':  Indicates whether IPv4, IPv6, or both address
         families are to be activated.

      'area-address':  Indicates the IS-IS area address.

      'level':  Indicates the IS-IS level: Level 1, Level2, or both.

      'metric':  Associates a metric with IS-IS routes.

      'mode':  Indicates the IS-IS interface mode type.  It (Static Mode)

7.6.3.  CE-PE Routing Protocols

   A VPN service provider can be set
         to 'active' (that is, send configure one or receive IS-IS more routing protocols
   associated with a particular 'vpn-network-access'.  Such routing
   protocol control
         packets) or 'passive' (that is, suppress is enabled between the sending of IS-IS
         updates through PE and the interface).

      'security':  Controls CE.  Each instance is
   uniquely identified to accommodate scenarios where multiple instances
   of the authentication schemes same routing protocol have to be enabled for
         the IS-IS instance.

      'status':  Indicates configured on the status same link.

   The subtree of the OSPF routing instance. 'routing-protocols' is shown in Figure 14.

              ...
              +--rw routing-protocols
  | vpn-network-accesses
                 +--rw routing-protocol* vpn-network-access* [id]
  |
                    ...
  |
                    +--rw isis {vpn-common:rtg-isis}?
  | routing-protocols
                    |  +--rw address-family?   identityref
  | routing-protocol* [id]
                    |     +--rw area-address      yang:dotted-quad
  | id   string
                    |     +--rw level? type?               identityref
                    |     |  +--rw metric?           uint16
  |     |  +--rw mode?             enumeration
  |     |  +--rw security
  |     |  |     +--rw enable?            boolean
  | routing-profiles* [id]
                    |     |  +--rw keying-material
  | id      leafref
                    |     |  +--rw (option)?
  |     |  |        +--:(auth-key-chain)
  |     |  | type?   identityref
                    |     +--rw key-chain?          key-chain:key-chain-ref
  |     |  |        +--:(auth-key-explicit) static
                    |     |  ...
                    |     +--rw key-id?             uint32 bgp {vpn-common:rtg-bgp}?
                    |     |  ...
                    |     +--rw key?                string ospf {vpn-common:rtg-ospf}?
                    |     |  ...
                    |     +--rw crypto-algorithm?   identityref
  | isis {vpn-common:rtg-isis}?
                    |  +--rw status     |  ...
                    |     +--rw admin-status rip {vpn-common:rtg-rip}?
                    |     |  ...
                    |     +--rw status?        identityref
  |     | vrrp {vpn-common:rtg-vrrp}?
                    |        ...
                    +--rw last-updated?  yang:date-and-time
  |     |     +--ro oper-status
  |     |        +--ro status?        identityref
  |     |        +--ro last-updated?  yang:date-and-time security
                        ...

                   Figure 18: IS-IS 14: Routing Subtree Structure

   RIP:

   Multiple routing instances can be defined; each uniquely identified
   by an 'id'.  The module covers only a list type of address-family and status as
      shown a routing instance is indicated in Figure 19. 'type'.
   The meaning values of this attributes are those defined in
   [I-D.ietf-opsawg-vpn-common] ('routing-protocol-type' identity).

   Configuring multiple instances of these data nodes is similar to the other same routing protocols.

          ...
          +--rw routing-protocols
          |  +--rw routing-protocol* [id]
          |     ...
          |     +--rw rip {vpn-common:rtg-rip}?
          |     |  +--rw address-family*   identityref
          |     |  +--rw status
          |     |     +--rw admin-status
          |     |     |  +--rw status?        identityref
          |     |     |  +--rw last-updated?  yang:date-and-time
          |     |     +--ro oper-status
          |     |        +--ro status?        identityref
          |     |        +--ro last-updated?  yang:date-and-time
          ...

                     Figure 19: RIP Subtree Structure

   VRRP:  The model (Figure 20) allows to enable VRRP protocol does not
   automatically imply that, from a device configuration perspective,
   there will be parallel instances (e.g., multiple processes) running
   on the 'vpn-
      network-access' interface.  The following data nodes are
      supported:

      'address-family':  Indicates whether IPv4, IPv6, or both address
         families are PE-CE link.  It is up to be activated.  Note that VRRP version 3
         [RFC5798] supports both IPv4 and IPv6.

      'vrrp-group':  Is used each implementation to identify the VRRP group.

      'backup-peer':  Carries decide about
   the IP address appropriate configuration as a function of the peer

      'priority':  Assigns the VRRP election priority for the backup
         virtual router.

      'ping-reply':  Controls whether ping requests can underlying
   capabilities and service provider operational guidelines.  As an
   example, when multiple BGP peers need to be replied to.

      'status':  Indicates the status implemented, multiple
   instances of the VRRP instance.

      Note that no security data node is included for VRRP BGP must be configured as there
      isn't currently any type part of VRRP authentication (see Section 9 this model.  However,
   from a device configuration point of
      [RFC5798]).

          ...
          +--rw routing-protocols
          |  +--rw routing-protocol* [id]
          |     ...
          |     +--rw vrrp {vpn-common:rtg-vrrp}?
          |        +--rw address-family*   identityref
          |        +--rw vrrp-group?       uint8
          |        +--rw backup-peer?      inet:ip-address
          |        +--rw priority?         uint8
          |        +--rw ping-reply?       boolean
          |        +--rw status
          |           +--rw admin-status
          |           |  +--rw status?        identityref
          |           |  +--rw last-updated?  yang:date-and-time
          |           +--ro oper-status
          |              +--ro status?        identityref
          |              +--ro last-updated?  yang:date-and-time
          ...

                     Figure 20: VRRP Subtree Structure

7.6.4.  OAM

   This container (Figure 21) defines the Operations, Administration,
   and Maintenance (OAM) mechanisms used for view, this could be implemented
   as:

   o  Multiple BGP processes with a VPN network access.  In single neighbor running in each
      process.

   o  A single BGP process with multiple neighbors running.

   o  A combination thereof.

   Routing configuration does not include low-level policies.  Such
   policies are handed at the current version device configuration level.  Local
   policies of the L3NM, only BFD is supported.  The current
   data nodes can a service provider (e.g., filtering) will be specified:

   holdtime':  Is used to indicate implemented
   as part of the expected BFD holddown time.  The
      value can be set by device configuration; these are not captured in the customer or selected from a profile.

   'security':  Includes
   L3NM, but the required information model allows to enable the BFD
      authentication modes discussed in Section 6.7 of [RFC5880].  In
      particular 'meticulous' controls associate local profiles with routing
   instances ('routing-profiles').

   The L3NM supports the activation configuration of one or more IPv4/IPv6 static
   routes.  Since the meticulous
      mode discussed in Sections 6.7.3 same structure is used for both IPv4 and 6.7.4 IPv6, it
   was considered to have one single container to group both static
   entries independently of [RFC5880].

   'status': their address family, but that design was
   abandoned to ease the mapping with the structure in [RFC8299].  As
   depicted in Figure 15, the following data nodes can be defined for a
   given IP prefix:

   'lan-tag':  Indicates a local tag (e.g., "myfavourite-lan") that is
      used to enforce local policies.

   'next-hop':  Indicates the next-hop to be used for the static route.
      It can be identified by an IP address, an interface, etc.

   'bfd-enable':  Indicates whether BFD is enabled or disabled for this
      static route entry.

   'metric':  Indicates the metric associated with the static route
      entry.

   'preference':  Indicates the preference associated with the static
      route entry.  This preference is used to selecting a preferred
      route among routes to the same destination prefix.

   'status':  Used to convey the status of BFD. a static route entry.  This
      data node is used to control the (de)activation of individual
      static route entries.

       ...
       +--rw oam routing-protocols
       |  +--rw bfd {vpn-common:bfd}? routing-protocol* [id]
       |     +--rw (holdtime)?     ...
       |     +--rw static
       |  +--:(fixed)     |  +--rw cascaded-lan-prefixes
       |     |     +--rw fixed-value?    uint32 ipv4-lan-prefixes*
       |     |  +--:(profile)     |       [lan next-hop]
       |     |     |       {vpn-common:ipv4}?
       |     |     |  +--rw profile-name?   leafref lan         inet:ipv4-prefix
       |     |     |  +--rw authentication! lan-tag?      string
       |     |     |  +--rw key-chain?    key-chain:key-chain-ref next-hop      union
       |     |     |  +--rw meticulous? bfd-enable?   boolean
       |     |     |  +--rw metric?       uint32
       |     |     |  +--rw preference?   uint32
       |     |     |  +--rw status
       |     |     |     +--rw admin-status
       |     |     |     |  +--rw status?         identityref
       |     |     |     |  +--rw last-updated?   yang:date-and-time
       |     |     |     +--ro oper-status
       |     |     |        +--ro status?         identityref
       |     |     |        +--ro last-updated?   yang:date-and-time
   ...

             Figure 21: IP Connection Subtree Structure (OAM)

7.6.5.  Security

   The 'security' container specifies the authentication and the
   encryption to be applied for a given VPN network access traffic.  As
   depicted in the subtree shown in Figure 22, the L3NM can be used to
   directly control the encryption to put in place (e.g., Layer 2 or
   Layer 3 encryption) or invoke a local encryption profile.

       ...
       +--rw vpn-services
          +--rw vpn-service* [vpn-id]
             ...
             +--rw vpn-nodes
                +--rw vpn-node* [vpn-node-id]
                   ...
       |     |     +--rw vpn-network-accesses ipv6-lan-prefixes*
       |     |             [lan next-hop]
       |     |             {vpn-common:ipv6}?
       |     |        +--rw vpn-network-access* [id]
                         ... lan         inet:ipv6-prefix
       |     |        +--rw security lan-tag?      string
       |     |        +--rw encryption {vpn-common:encryption}? next-hop      union
       |     |        +--rw enabled? bfd-enable?   boolean
       |     |        +--rw layer?     enumeration metric?       uint32
       |  +--rw encryption-profile     |        +--rw (profile)? preference?   uint32
       |        +--:(provider-profile)     |        +--rw status
       |     |           +--rw profile-name?         leafref admin-status
       |     |        +--:(customer-profile)           |  +--rw customer-key-chain? status?         identityref
       |     |           |                   kc:key-chain-ref  +--rw service last-updated?   yang:date-and-time
       |     |           +--ro oper-status
       |     |              +--ro status?         identityref
       |     |              +--ro last-updated?   yang:date-and-time
       ...

                Figure 22: Security 15: Static Routing Subtree Structure

7.6.6.  Services

   The 'services' container specifies

   In addition, the service parameters L3NM supports the following CE-PE routing protocols:

   BGP:  The L3NM allows to apply
   for configure a given VPN BGP neighbor, including a set
      for parameters that are pertinent to be tweaked at the network access (Figure 23).

             ...
             +--rw vpn-network-accesses
                +--rw vpn-network-access* [id]
                   ...
                   +--rw
      level for service
                      +--rw input-bandwidth     uint64
                      +--rw output-bandwidth    uint64
                      +--rw mtu                 uint16
                      +--rw qos {vpn-common:qos}?
                      |  ...
                      +--rw carrierscarrier
                      |       {vpn-common:carrierscarrier}?
                      |  +--rw signalling-type?   enumeration
                      +--rw multicast {vpn-common:multicast}?
                         ...

                   Figure 23: Services Subtree Structure customization purposes.

      This container does not aim to include every BGP parameter; a
      comprehensive set of parameters belongs more to the BGP device
      model.

      The following data nodes are defined:

   'input-bandwidth':  Indicates the inbound bandwidth of captured in Figure 16.  It is up to
      the connection
      (i.e., download bandwidth from the SP implementation to derive the site).

   'output-bandwidth':  Indicates the outbound bandwidth corresponding BGP device
      configuration:

      'description':  Includes a description of the
      connection (i.e., upload bandwidth from BGP session.

      'local-autonomous-system':  Indicates a local AS Number (ASN) if a
         distinct ASN than the site to one configured at the SP).

   'mtu': VPN node level is
         needed.

      'peer-autonomous-system':  Conveys the customer's ASN.

      'address-family':  Indicates the MTU at service level. address-family of the peer.  It
         can be the IP MTU or
      MPLS MTU, for example.

   'qos':  Is used set to define IPv4, IPv6, or dual-stack.

      'local-address':  Specifies an address or a set of QoS policies reference to apply on an
         interface to use when establishing the BGP transport session.

      'neighbor':  Can indicate two neighbors (each for a given
      connection (Figure 24). address-
         family) or one neighbor (if 'address-family' attribute is set
         to dual-stack).  A QoS policy may list of IP address(es) of the BGP neighbors
         can be then conveyed in this data node.

      'multihop':  Indicates the number of allowed IP hops between a classification or
      an action policy.  For example, a QoS action can PE
         and its BGP peer.

      'as-override':  If set, this parameter indicates whether ASN
         override is enabled, i.e., replace the ASN of the customer
         specified in the AS_PATH BGP attribute with the ASN identified
         in the 'local-autonomous-system' attribute.

      'allow-own-as':  Is used in some topologies (e.g., hub-and-spoke)
         to allow the provider's ASN to be defined included in the AS_PATH BGP
         attribute received from a CE.  Loops are prevented by setting
         'allow-own-as' to
      rate limit inbound/outbound traffic of a given class maximum number of service.

              ...
              +--rw qos {vpn-common:qos}?
              |  +--rw qos-classification-policy
              |  |  +--rw rule* [id]
              |  |     +--rw id             string
              |  |     +--rw (match-type)?
              |  |     |  +--:(match-flow)
              |  |     |  |  +--rw (l3)?
              |  |     |  |  |  +--:(ipv4)
              |  |     |  |  |  |  ...
              |  |     |  |  |  +--:(ipv6)
              |  |     |  |  |     ...
              |  |     |  |  +--rw (l4)?
              |  |     |  |     +--:(tcp)
              |  |     |  |     |  ...
              |  |     |  |     +--:(udp)
              |  |     |  |        ...
              |  |     |  +--:(match-application)
              |  |     |     +--rw match-application?
              |  |     |             identityref
              |  |     +--rw target-class-id?
              |  |             string
              |  +--rw qos-action
              |  |  +--rw rule* [id]
              |  |     +--rw id                     string
              |  |     +--rw target-class-id?       string
              |  |     +--rw inbound-rate-limit?    decimal64
              |  |     +--rw outbound-rate-limit?   decimal64
              |  +--rw qos-profile
              |     +--rw qos-profile* [profile]
              |        +--rw profile      leafref
              |        +--rw direction?   identityref
              ...

                   Figure 24: Services Subtree Structure

      QoS classification can be based on many criteria such as:

      Layer 3:  As shown provider's ASN
         occurrences.  This parameter is set by default to '0' (that is,
         reject any AS_PATH attribute that includes the provider's ASN).

      'prepend-global-as':  When distinct ASNs are configured in Figure 26, classification the VPN
         node and network access levels, this parameter controls whether
         the ASN provided at the VPN node level is prepended to the
         AS_PATH attribute.

      'default-route':  Controls whether default routes can be based on
         any IP header field or
         advertised to the peer.

      'site-of-origin':  Is meant to uniquely identify the set of routes
         learned from a combination thereof.  Both IPv4 site via a particular CE/PE connection and is
         used to prevent routing loops (Section 7 of [RFC4364]).  The
         Site of Origin attribute is encoded as a Route Origin Extended
         Community.

      'ipv6-site-of-origin':  Carries an IPv6 are supported. Address Specific BGP
         Extended that is used to indicate the Site of Origin for VRF
         information [RFC5701].  It is used to prevent routing loops.

      'redistribute-connected':  Controls whether the PE-CE link is
         advertised to other PEs.

      'bgp-max-prefix':  Controls the behavior when a prefix maximum is
         reached.

         'max-prefix':  Indicates the maximum number of BGP prefixes
            allowed in the BGP session.  If such limit is reached, the
            action indicated in 'action-violate' will be followed.

         'warning-threshold':  A warning notification is triggered when
            this limit is reached.

         'violate-action':  Indicates which action to execute when the
            maximum number of BGP prefixes is reached.  Examples of such
            actions are: send a warning message, discard extra paths
            from the peer, or restart the session.

      'bgp-timers':   Two timers can be captured in this container: (1)
         'hold-time' which is the time interval that will be used for
         the HoldTimer (Section 4.2 of [RFC4271]) when establishing a
         BGP session.  (2) 'keep-alive' which is the time interval for
         the KeepAlive timer between a PE and a BGP peer (Section 4.4 of
         [RFC4271]).

      'security':  The module adheres to the recommendations in
         Section 13.2 of [RFC4364] as it allows to enable TCP-AO
         [RFC5925] and accommodates the installed base that makes use of
         MD5.  In addition, the module includes a provision for the use
         of IPsec.

      'status':  Indicates the status of the BGP routing instance.

  ...
  +--rw qos {vpn-common:qos}? routing-protocols
  |  +--rw qos-classification-policy routing-protocol* [id]
  |     ...
  |     +--rw rule* [id] bgp {vpn-common:rtg-bgp}?
  |     |  +--rw id description?               string
  |     |  +--rw (match-type)?
       |  |     |  +--:(match-flow) local-autonomous-system?   inet:as-number
  |     |  +--rw peer-autonomous-system     inet:as-number
  |     |  +--rw (l3)? address-family?            identityref
  |     |  +--rw local-address?             union
  |     |  |  +--:(ipv4)
       |  |     |  |  |  |  +--rw ipv4
       |  |  +--rw neighbor*                  inet:ip-address
  |     |  +--rw multihop?                  uint8
  |     |  +--rw dscp?              inet:dscp
       |  |     |  | as-override?               boolean
  |     |  +--rw ecn? allow-own-as?              uint8
  |     |     |  |  |  |  +--rw length?            uint16 prepend-global-as?         boolean
  |     |  +--rw default-route?             boolean
  |     |  +--rw site-of-origin?            rt-types:route-origin
  |     |  +--rw ttl?               uint8
       | ipv6-site-of-origin?       rt-types:ipv6-route-origin
  |     |  +--rw redistribute-connected* [address-family]
  |     |  |  +--rw protocol?          uint8
       | address-family    identityref
  |     |  |  +--rw enable?           boolean
  |     |  +--rw ihl?               uint8 bgp-max-prefix
  |     |  |  +--rw max-prefix?          uint32
  |     |  |  +--rw flags?             bits warning-threshold?   decimal64
  |     |  |  +--rw violate-action?      enumeration
  |     |  |  +--rw offset? restart-interval?    uint16
  |     |     |  +--rw bgp-timers
  |     |  |  +--rw identification? keep-alive?   uint16
  |     |  |  |  |  |  +--rw (destination-network)?
       |  |     |  |  |  |     |  +--:(destination-ipv4-network)
       |  |     |  |  | hold-time?    uint16
  |     |  +--rw destination-ipv4-network?
       |  |     |  |  |  |     |             inet:ipv4-prefix
       |  |     | security
  |     |  |  +--rw (source-network)?
       |  |     |  |  |  |        +--:(source-ipv4-network)
       |  |     | enable?            boolean
  |     |  |  +--rw source-ipv4-network?
       |  |     |  |  |  |  inet:ipv4-prefix keying-material
  |     |  |     +--rw (option)?
  |     |  +--:(ipv6)  |        +--:(tcp-ao)
  |     |  |        |  +--rw ipv6
       | enable-tcp-ao?      boolean
  |     |  |        |  +--rw dscp?              inet:dscp
       |  |     | ao-keychain?        key-chain:key-chain-ref
  |     |        +--rw ecn?               uint8  |        +--:(md5)
  |     |  |        |  +--rw length?            uint16
       |  |     | md5-keychain?   key-chain:key-chain-ref
  |     |        +--rw ttl?               uint8  |        +--:(explicit)
  |     |  |        |  +--rw protocol?          uint8
       | key-id?             uint32
  |     |  |        |  +--rw (destination-network)?
       |  |     |  |  |        |  +--:(destination-ipv6-network)
       |  | key?                string
  |     |  |        |  +--rw destination-ipv6-network?
       |  |     |  |  | crypto-algorithm?   identityref
  |             inet:ipv6-prefix     |  |        +--:(ipsec)
  |     |  |           +--rw (source-network)?
       |  |     |  |  |        |  +--:(source-ipv6-network)
       |  |     |  | sa?             string
  |     |  +--rw source-ipv6-network?
       |  |     | status
  |     |     +--rw admin-status
  |             inet:ipv6-prefix     |     |  +--rw status?         identityref
  |     |     |  +--rw flow-label? last-updated?   yang:date-and-time
  |     |     +--ro oper-status
  |     |        +--ro status?         identityref
  |     |                   inet:ipv6-flow-label        +--ro last-updated?   yang:date-and-time
  ...

                 Figure 25: QoS 16: BGP Routing Subtree Structure (L3)

      Layer 4:  As shown in Figure 26, TCP or UDP-related match crietria

   OSPF:  OSPF can be specified in configured to run as a routing protocol on the L3NM.

   +--rw qos {vpn-common:qos}?
   |  +--rw qos-classification-policy
   |  |  +--rw rule* [id]
   |
      'vpn-network-access'.  The following data nodes are captured in
      Figure 17:

      'address-family':  Indicates whether IPv4, IPv6, or both address
         families are to be activated.

         When only the IPv4 address-family is requested, it will be up
         to the implementation to decide whether OSPFv2 [RFC4577] or
         OSPFv3 [RFC6565] is used.

      'area-id':  Indicates the OSPF Area ID.

      'metric':  Associates a metric with OSPF routes.

      'sham-links':  Is used to create OSPF sham links between two VPN
         network accesses sharing the same area and having a backdoor
         link (Section 4.2.7 of [RFC4577] and Section 5 of [RFC6565]).

      'max-lsa':  Sets the maximum number of LSAs that the OSPF instance
         will accept.

      'security':  Controls the authentication schemes to be enabled for
         the OSPF instance.  The following options are supported: IPsec
         for OSPFv3 authentication [RFC4552], authentication trailer for
         OSPFv2 [RFC5709] [RFC7474] and OSPFv3 [RFC7166].

      'status':  Indicates the status of the OSPF routing instance.

        ...
        +--rw routing-protocols
        |  +--rw id           string routing-protocol* [id]
        |     ...
        |     +--rw (match-type)?
   | ospf {vpn-common:rtg-ospf}?
        |     |  +--:(match-flow)  +--rw address-family?   identityref
        |     |  +--rw area-id           yang:dotted-quad
        |     |  +--rw (l3)?
   | metric?           uint16
        |     |  +--rw sham-links  {vpn-common:rtg-ospf-sham-link}?
        |     |  ...  |  +--rw sham-link* [target-site]
        |     |  |     +--rw (l4)?
   |  | target-site
        |     |     +--:(tcp)  |     |       vpn-common:vpn-id
        |     |  |     +--rw tcp
   |  |     | metric?        uint16
        |     |  +--rw sequence-number? max-lsa?          uint32
        |     |     |  |     |  +--rw acknowledgement-number?   uint32
   |  | security
        |     |  |  +--rw data-offset?              uint8
   |  | enable?            boolean
        |     |  |  +--rw reserved?                 uint8
   |  | keying-material
        |     |  |     +--rw flags?                    bits
   |  |     | (option)?
        |     |     +--rw window-size?              uint16  |        +--:(md5)
        |     |  |        |  +--rw urgent-pointer?           uint16 md5-keychain?
        |     |  |        |          kc:key-chain-ref
        |     +--rw options?                  binary     |  |        +--:(ipsec)
        |     |  |           +--rw (source-port)?
   |  |     |  |     |     |  +--:(source-port-range-or-operator)
   |  | sa?  string
        |     |  +--rw status
        |     |     +--rw source-port-range-or-operator admin-status
        |     |     |  +--rw status?        identityref
        |     |     |  +--rw (port-range-or-operator)?
   |  |     |  |     |     |           +--:(range)
   | last-updated?  yang:date-and-time
        |     |     +--ro oper-status
        |     |        +--ro status?        identityref
        |     |        +--ro last-updated?  yang:date-and-time
        ...

                 Figure 17: OPSF Routing Subtree Structure

   IS-IS:  The model (Figure 18) allows the user to configure IS-IS to
      run on the 'vpn-network-access' interface.  The following IS-IS
      data nodes are supported:

      'address-family':  Indicates whether IPv4, IPv6, or both address
         families are to be activated.

      'area-address':  Indicates the IS-IS area address.

      'level':  Indicates the IS-IS level: Level 1, Level2, or both.

      'metric':  Associates a metric with IS-IS routes.

      'mode':  Indicates the IS-IS interface mode type.  It can be set
         to 'active' (that is, send or receive IS-IS protocol control
         packets) or 'passive' (that is, suppress the sending of IS-IS
         updates through the interface).

      'security':  Controls the authentication schemes to be enabled for
         the IS-IS instance.

      'status':  Indicates the status of the OSPF routing instance.

  ...
  +--rw lower-port
   |  |     |  |     |     |           |  |       inet:port-number
   |  |     |  |     |     | routing-protocols
  |  +--rw upper-port
   |  |     |  |     |     |           |          inet:port-number
   |  |     |  |     |     |           +--:(operator)
   |  |     |  | routing-protocol* [id]
  |     ...
  |     +--rw operator? operator
   |  |     |  | isis {vpn-common:rtg-isis}?
  |     |  +--rw port
   |  |     |  |     |     |                      inet:port-number
   | address-family?   identityref
  |     |  +--rw area-address      area-address
  |     |  +--rw (destination-port)? level?            identityref
  |     |  +--rw metric?           uint16
  |     |     +--:(destination-port-range-or-operator)  +--rw mode?             enumeration
  |     |  +--rw security
  |     |  |  +--rw destination-port-range-or-operator
   |  | enable?            boolean
  |     |  |  +--rw (port-range-or-operator)?
   | keying-material
  |     |  |     +--rw (option)?
  |                +--:(range)     |  |        +--:(auth-key-chain)
  |     |  |        |  +--rw lower-port
   |  |     |  | key-chain?          key-chain:key-chain-ref
  |     |  |       inet:port-number        +--:(auth-key-explicit)
  |     |  |           +--rw key-id?             uint32
  |     |  |           +--rw upper-port key?                string
  |     |  |           +--rw crypto-algorithm?   identityref
  |     |  +--rw status
  |          inet:port-number     |     +--rw admin-status
  |     |     |  +--rw status?        identityref
  |                +--:(operator)     |     |  +--rw last-updated?  yang:date-and-time
  |     |     |                   +--rw operator? operator
   |     +--ro oper-status
  |     |        +--ro status?        identityref
  |     |        +--ro last-updated?  yang:date-and-time
  ...

                Figure 18: IS-IS Routing Subtree Structure

   RIP:  The model allows the user to configure RIP to run on the 'vpn-
      network-access' interface.  As shown in Figure 19, the following
      RIP data nodes are supported:

      'address-family':  Indicates whether IPv4, IPv6, or both address
         families are to be activated.  This parameter is used to
         determine whether RIPv2 [RFC2453] and/or RIPng are to be
         enabled [RFC2080].

      'timers':  Indicates the following timers:

         'update-interval':  Is the interval at which RIP updates are
            sent.

         'invalid-interval':  Is the interval before a RIP route is
            declared invalid.

         'holddown-interval':  Is the interval before better RIP routes
            are released.

         'flush-interval':  Is the interval before a route is removed
            from the routing table.

      'default-metric':  Sets the default RIP metric.

      'security':  Controls the authentication schemes to be enabled for
         the RIP instance.

      'status':  Indicates the status of the RIP routing instance.

  ...
  +--rw port
   |  |     |  |     |                           inet:port-number
   | routing-protocols
  |  +--rw routing-protocol* [id]
  |     ...
  |     +--:(udp)     +--rw rip {vpn-common:rtg-rip}?
  |     |  +--rw address-family?   identityref
  |     |  +--rw udp
   | timers
  |     |  |  +--rw length? update-interval?     uint16
  |     |  |  |  +--rw (source-port)?
   |  |     |  |           |  +--:(source-port-range-or-operator)
   |  | invalid-interval?    uint16
  |     |  |  +--rw source-port-range-or-operator
   |  | holddown-interval?   uint16
  |     |  |  +--rw (port-range-or-operator)?
   |  |     |  |           |           +--:(range)
   |  |     |  | flush-interval?      uint16
  |     |  +--rw lower-port
   |  |     |  |           |           |  |       inet:port-number
   |  |     |  | neighbor*         inet:ip-address
  |     |  +--rw upper-port
   |  |     |  |           |           |          inet:port-number
   |  | default-metric?   uint8
  |     |  +--rw security
  |           +--:(operator)     |  |  +--rw enable?            boolean
  |     |  |  +--rw operator?  operator
   |  | keying-material
  |     |  |     +--rw port
   |  | (option)?
  |     |  |                      inet:port-number        +--:(auth-key-chain)
  |     |  |        |  +--rw (destination-port)?
   |  | key-chain?          key-chain:key-chain-ref
  |     |              +--:(destination-port-range-or-operator)  |        +--:(auth-key-explicit)
  |     |  |           +--rw destination-port-range-or-operator
   | key?                string
  |     |  |           +--rw (port-range-or-operator)?
   |  | crypto-algorithm?   identityref
  |     |                       +--:(range)  +--rw status
  |     |     +--rw admin-status
  |     |     |  +--rw lower-port
   |  | status?        identityref
  |     |     |  +--rw last-updated?  yang:date-and-time
  |       inet:port-number     |     +--ro oper-status
  |     |        +--ro status?        identityref
  |     |  +--rw upper-port
   |  |     |        +--ro last-updated?  yang:date-and-time
  ...

                     Figure 19: RIP Subtree Structure

   VRRP:  The model (Figure 20) allows to enable VRRP on the 'vpn-
      network-access' interface.  The following data nodes are
      supported:

      'address-family':  Indicates whether IPv4, IPv6, or both address
         families are to be activated.  Note that VRRP version 3
         [RFC5798] supports both IPv4 and IPv6.

      'vrrp-group':  Is used to identify the VRRP group.

      'backup-peer':  Carries the IP address of the peer

      'priority':  Assigns the VRRP election priority for the backup
         virtual router.

      'ping-reply':  Controls whether ping requests can be replied to.

      'status':  Indicates the status of the VRRP instance.

      Note that no security data node is included for VRRP as there
      isn't currently any type of VRRP authentication (see Section 9 of
      [RFC5798]).

          ...
          +--rw routing-protocols
          |  +--rw routing-protocol* [id]
          |          inet:port-number     ...
          |     +--rw vrrp {vpn-common:rtg-vrrp}?
          |        +--rw address-family*   identityref
          |        +--rw vrrp-group?       uint8
          |                       +--:(operator)        +--rw backup-peer?      inet:ip-address
          |        +--rw priority?         uint8
          |        +--rw ping-reply?       boolean
          |        +--rw status
          |           +--rw operator?   operator admin-status
          |           |  +--rw status?        identityref
          |           |  +--rw port
   | last-updated?  yang:date-and-time
          |           +--ro oper-status
          |              +--ro status?        identityref
          |                                  inet:port-number              +--ro last-updated?  yang:date-and-time
          ...

                     Figure 26: QoS 20: VRRP Subtree Structure (L4)

      Application match:  Relies upon application-specific
         classification.

   'carrierscarrier':  Groups a set of parameters that are

7.6.4.  OAM

   This container (Figure 21) defines the Operations, Administration,
   and Maintenance (OAM) mechanisms used when CsC
      is enabled such for a VPN network access.  In
   the use current version of BGP for signalling purposes [RFC8277].

   'multicast':  Specifies the multicast mode and other L3NM, only BFD is supported.  The current
   data nodes such
      as the address-family.  Refer to Section 7.7.

7.7.  Multicast

   Multicast may can be enabled for a particular VPN at specified:

   holdtime':  Is used to indicate the VPN node and VPN
   network access levels (see Figure 27).  Some data nodes (e.g., max-
   groups) expected BFD holddown time.  The
      value can be controlled at set by the VPN node level customer or at selected from a profile.

   'security':  Includes the VPN network
   access.

                ...
                +--rw vpn-nodes
                   +--rw vpn-node* [vpn-node-id]
                      ...
                      +--rw multicast {vpn-common:multicast}?
                      |  ...
                      +--rw vpn-network-accesses
                         +--rw vpn-network-access* [id]
                            ...
                            +--rw service
                               ...
                               +--rw multicast {vpn-common:multicast}?
                                  ...

              Figure 27: Overall Multicast Subtree Structure

   Multicast-related data nodes at required information to enable the VPN node level are shown BFD
      authentication modes discussed in
   Figure 29.  Disabling multicast at Section 6.7 of [RFC5880].  In
      particular 'meticulous' controls the VPN node level will have an
   effect to disable it also at activation of the VPN network access level.  For IGMP,
   MLD, meticulous
      mode discussed in Sections 6.7.3 and PIM, Global data nodes that are defined at the VPN node
   level are applicable to all VPN network accesses whose corresponding
   nodes are not provided at 6.7.4 of [RFC5880].

   'status':  Indicates the VPN network access level.

   ...
   +--rw vpn-nodes
      +--rw vpn-node* [vpn-node-id]
         ...
         +--rw multicast {vpn-common:multicast}?
         |  +--rw status
         |  | of BFD.

   ...
   +--rw admin-status
         |  | oam
   |  +--rw status?         identityref
         |  | bfd {vpn-common:bfd}?
   |     +--rw last-updated?   yang:date-and-time
         |  |  +--ro oper-status
         | (holdtime)?
   |     +--ro status?         identityref     |  +--:(fixed)
   |     +--ro last-updated?   yang:date-and-time     |  +--rw tree-flavor*   identityref  |  +--rw rp fixed-value?    uint32
   |     |  +--rw rp-group-mappings  +--:(profile)
   |     |  |  +--rw rp-group-mapping* [id]
         |  | profile-name?   leafref
   |     +--rw id                  uint16
         | authentication!
   |     |  +--rw provider-managed
         |  | key-chain?    key-chain:key-chain-ref
   |     |  +--rw enabled? meticulous?   boolean
   |  |  |     |     +--rw rp-redundancy?              boolean
         |  |  | status
   |        +--rw optimal-traffic-delivery?   boolean
         |  | admin-status
   |           |  +--rw anycast
         |  | status?         identityref
   |           |  +--rw local-address?    inet:ip-address
         |  |  |     |     +--rw rp-set-address*   inet:ip-address last-updated?   yang:date-and-time
   |           +--ro oper-status
   |              +--ro status?         identityref
   |              +--ro last-updated?   yang:date-and-time
   ...

             Figure 21: IP Connection Subtree Structure (OAM)

7.6.5.  Security

   The 'security' container specifies the authentication and the
   encryption to be applied for a given VPN network access traffic.  As
   depicted in the subtree shown in Figure 22, the L3NM can be used to
   directly control the encryption to put in place (e.g., Layer 2 or
   Layer 3 encryption) or invoke a local encryption profile.

       ...
       +--rw rp-address          inet:ip-address
         |  |  | vpn-services
          +--rw groups
         |  |  | vpn-service* [vpn-id]
             ...
             +--rw group* vpn-nodes
                +--rw vpn-node* [vpn-node-id]
                   ...
                   +--rw vpn-network-accesses
                      +--rw vpn-network-access* [id]
         |  |  |
                         ...
                         +--rw id                     uint16
         |  | security
                         |  +--rw (group-format)
         |  |  |              +--:(group-prefix)
         |  | encryption {vpn-common:encryption}?
                         |  |  +--rw group-address?   inet:ip-prefix
         |  | enabled?   boolean
                         |              +--:(startend)  |  +--rw layer?     enumeration
                         |  +--rw encryption-profile
                         |     +--rw group-start?     inet:ip-address (profile)?
                         |        +--:(provider-profile)
                         |        |  +--rw group-end?       inet:ip-address profile-name?         leafref
                         |        +--:(customer-profile)
                         |           +--rw rp-discovery
         | customer-key-chain?
                         |                   kc:key-chain-ref
                         +--rw rp-discovery-type?   identityref
         | service
                             ...

                   Figure 22: Security Subtree Structure

7.6.6.  Services

   The 'service' container specifies the service parameters to apply for
   a given VPN network access (Figure 23).

        ...
        +--rw vpn-network-accesses
           +--rw vpn-network-access* [id]
              ...
              +--rw service
                 +--rw input-bandwidth     uint64
                 +--rw output-bandwidth    uint64
                 +--rw mtu                 uint16
                 +--rw qos {vpn-common:qos}?
                 |  ...
                 +--rw bsr-candidates carrierscarrier
                 |       {vpn-common:carrierscarrier}?
                 |  +--rw bsr-candidate-address*   inet:ip-address
         | signalling-type?   enumeration
                 +--rw msdp {msdp}? ntp
                 |  +--rw broadcast?      enumeration
                 |  +--rw peer?            inet:ip-address auth-profile
                 |  |  +--rw local-address?   inet:ip-address
         | profile-id?   string
                 |  +--rw status
                 |  |     +--rw admin-status
                 |     |     |  +--rw status?         identityref
                 |     |     |  +--rw last-updated?   yang:date-and-time
                 |  |     +--ro oper-status
                 |  |        +--ro status?         identityref
                 |  |        +--ro last-updated?   yang:date-and-time
         |  +--rw igmp {vpn-common:igmp and vpn-common:ipv4}?
         |  |  +--rw static-group* [group-addr]
         |  |  |  +--rw group-addr
         |  |  |        rt-types:ipv4-multicast-group-address
         |  |  |
                 +--rw source-addr?
         |  |  |        rt-types:ipv4-multicast-source-address
         |  |  +--rw max-groups?     uint32
         |  |  +--rw max-entries?    uint32
         | multicast {vpn-common:multicast}?
                    ...

                   Figure 23: Services Subtree Structure

   The following data nodes are defined:

   'input-bandwidth':  Indicates the inbound bandwidth of the connection
      (i.e., download bandwidth from the service provider to the site).

   'output-bandwidth':  Indicates the outbound bandwidth of the
      connection (i.e., upload bandwidth from the site to the service
      provider).

   'mtu':  Indicates the MTU at service level.  It can be the IP MTU or
      MPLS MTU, for example.

   'qos':  Is used to define a set of QoS policies to apply on a given
      connection (Figure 24).  A QoS policy may be a classification or
      an action policy.  For example, a QoS action can be defined to
      rate limit inbound/outbound traffic of a given class of service.

              ...
              +--rw qos {vpn-common:qos}?
              |  +--rw version?        identityref qos-classification-policy
              |  |  +--rw status rule* [id]
              |  |     +--rw admin-status
         | id             string
              |  |     +--rw status?         identityref (match-type)?
              |  |     |  +--:(match-flow)
              |  |     |  |  +--rw last-updated?   yang:date-and-time (l3)?
              |  |     +--ro oper-status     |  |        +--ro status?         identityref  |  +--:(ipv4)
              |        +--ro last-updated?   yang:date-and-time  |  +--rw mld {vpn-common:mld and vpn-common:ipv6}?     |  |  +--rw static-group* [group-addr]  |  |  ...
              |  +--rw group-addr  |     |  |        rt-types:ipv6-multicast-group-address  |  +--:(ipv6)
              |  |  +--rw source-addr?     |  |  |        rt-types:ipv6-multicast-source-address     ...
              |  |  +--rw max-groups?     uint32     |  |  +--rw max-entries?    uint32 (l4)?
              |  |     |  |     +--:(tcp)
              |  |     |  |     |  ...
              |  |     |  |     +--:(udp)
              |  |     |  |        ...
              |  |     |  +--:(match-application)
              |  |     |     +--rw version? match-application?
              |  |     |             identityref
              |  |     +--rw status target-class-id?
              |  |     +--rw admin-status             string
              |  +--rw qos-action
              |  |  +--rw status?         identityref rule* [id]
              |  |     +--rw id                     string
              |  |     +--rw last-updated?   yang:date-and-time target-class-id?       string
              |  |     +--ro oper-status     +--rw inbound-rate-limit?    decimal64
              |  |        +--ro status?         identityref     +--rw outbound-rate-limit?   decimal64
              |  +--rw qos-profile
              |        +--ro last-updated?   yang:date-and-time     +--rw qos-profile* [profile]
              |        +--rw profile      leafref
              |        +--rw pim {vpn-common:pim}? direction?   identityref
              ...

                   Figure 24: Services Subtree Structure

      QoS classification can be based on many criteria such as:

      Layer 3:  As shown in Figure 25, classification can be based on
         any IP header field or a combination thereof.  Both IPv4 and
         IPv6 are supported.

       +--rw qos {vpn-common:qos}?
       |  +--rw qos-classification-policy
       |  |  +--rw rule* [id]
       |  |     +--rw id           string
       |  |     +--rw (match-type)?
       |  |     |  +--:(match-flow)
       |  |     |  |  +--rw (l3)?
       |  |     |  |  |  +--:(ipv4)
       |  |     |  |  |  |  +--rw ipv4
       |  |     |  |  |  |     +--rw dscp?              inet:dscp
       |  |     |  |  |  |     +--rw ecn?               uint8
       |  |     |  |  |  |     +--rw length?            uint16
       |  |     |  |  |  |     +--rw ttl?               uint8
       |  |     |  |  |  |     +--rw protocol?          uint8
       |  |     |  |  |  |     +--rw ihl?               uint8
       |  |     |  |  |  |     +--rw flags?             bits
       |  |     |  |  |  |     +--rw offset?            uint16
       |  |     |  |  |  |     +--rw identification?    uint16
       |  |     |  |  |  |     +--rw (destination-network)?
       |  |     |  |  |  |     |  +--:(destination-ipv4-network)
       |  |     |  |  |  |     |     +--rw destination-ipv4-network?
       |  |     |  |  |  |     |             inet:ipv4-prefix
       |  |     |  |  |  |     +--rw (source-network)?
       |  |     |  |  |  |        +--:(source-ipv4-network)
       |  |     |  |  |  |           +--rw source-ipv4-network?
       |  |     |  |  |  |  inet:ipv4-prefix
       |  |     |  |  |  +--:(ipv6)
       |  |     |  |  |     +--rw ipv6
       |  |     |  |  |        +--rw dscp?              inet:dscp
       |  |     |  |  |        +--rw ecn?               uint8
       |  |     |  |  |        +--rw length?            uint16
       |  |     |  |  |        +--rw ttl?               uint8
       |  |     |  |  |        +--rw protocol?          uint8
       |  |     |  |  |        +--rw (destination-network)?
       |  |     |  |  |        |  +--:(destination-ipv6-network)
       |  |     |  |  |        |     +--rw destination-ipv6-network?
       |  |     |  |  |        |             inet:ipv6-prefix
       |  |     |  |  |        +--rw (source-network)?
       |  |     |  |  |        |  +--:(source-ipv6-network)
       |  |     |  |  |        |     +--rw source-ipv6-network?
       |  |     |  |  |        |             inet:ipv6-prefix
       |  |     |  |  |        +--rw flow-label?
       |  |     |  |  |                   inet:ipv6-flow-label
       ...

                   Figure 25: QoS Subtree Structure (L3)

      Layer 4:  As discussed in [I-D.ietf-opsawg-vpn-common], any layer
         4 protocol can be indicated in the 'protocol' data node under
         'l3' (Figure 25), but only TCP and UDP specific match criteria
         are elaborated in this version as these protocols are widely
         used in the context of VPN services.  Augmentations can be
         considered in the future to add other Layer 4 specific data
         nodes, if needed.

         TCP or UDP-related match crietria can be specified in the L3NM
         as shown in Figure 26.

   +--rw qos {vpn-common:qos}?
   |  +--rw qos-classification-policy
   |  |  +--rw rule* [id]
   |  |     +--rw id           string
   |  |     +--rw (match-type)?
   |  |     |  +--:(match-flow)
   |  |     |  |  +--rw (l3)?
   |  |     |  |  |  ...
   |  |     |  |  +--rw (l4)?
   |  |     |  |     +--:(tcp)
   |  |     |  |     |  +--rw tcp
   |  |     |  |     |     +--rw sequence-number?          uint32
   |  |     |  |     |     +--rw acknowledgement-number?   uint32
   |  |     |  |     |     +--rw data-offset?              uint8
   |  |     |  |     |     +--rw reserved?                 uint8
   |  |     |  |     |     +--rw flags?                    bits
   |  |     |  |     |     +--rw window-size?              uint16
   |  |     |  |     |     +--rw urgent-pointer?           uint16
   |  |     |  |     |     +--rw options?                  binary
   |  |     |  |     |     +--rw (source-port)?
   |  |     |  |     |     |  +--:(source-port-range-or-operator)
   |  |     |  |     |     |     +--rw source-port-range-or-operator
   |  |     |  |     |     |        +--rw (port-range-or-operator)?
   |  |     |  |     |     |           +--:(range)
   |  |     |  |     |     |           |  +--rw lower-port
   |  |     |  |     |     |           |  |       inet:port-number
   |  |     |  |     |     |           |  +--rw upper-port
   |  |     |  |     |     |           |          inet:port-number
   |  |     |  |     |     |           +--:(operator)
   |  |     |  |     |     |              +--rw operator? operator
   |  |     |  |     |     |              +--rw port
   |  |     |  |     |     |                      inet:port-number
   |  |     |  |     |     +--rw (destination-port)?
   |  |     |  |     +--:(destination-port-range-or-operator)
   |  |     |  |     |          +--rw destination-port-range-or-operator
   |  |     |  |     |             +--rw (port-range-or-operator)?
   |  |     |  |     |                +--:(range)
   |  |     |  |     |                |  +--rw lower-port
   |  |     |  |     |                |  |       inet:port-number
   |  |     |  |     |                |  +--rw upper-port
   |  |     |  |     |                |          inet:port-number
   |  |     |  |     |                +--:(operator)
   |  |     |  |     |                   +--rw operator? operator
   |  |     |  |     |                   +--rw port
   |  |     |  |     |                           inet:port-number
   |  |     |  |     +--:(udp)
   |  |     |  |        +--rw udp
   |  |     |  |           +--rw length?                    uint16
   |  |     |  |           +--rw (source-port)?
   |  |     |  |           |  +--:(source-port-range-or-operator)
   |  |     |  |           |     +--rw source-port-range-or-operator
   |  |     |  |           |        +--rw (port-range-or-operator)?
   |  |     |  |           |           +--:(range)
   |  |     |  |           |           |  +--rw lower-port
   |  |     |  |           |           |  |       inet:port-number
   |  |     |  |           |           |  +--rw upper-port
   |  |     |  |           |           |          inet:port-number
   |  |     |  |           |           +--:(operator)
   |  |     |  |           |              +--rw operator?  operator
   |  |     |  |           |              +--rw port
   |  |     |  |           |                      inet:port-number
   |  |     |  |           +--rw (destination-port)?
   |  |     |  |              +--:(destination-port-range-or-operator)
   |  |     |  |                +--rw destination-port-range-or-operator
   |  |     |  |                    +--rw (port-range-or-operator)?
   |  |     |  |                       +--:(range)
   |  |     |  |                       |  +--rw lower-port
   |  |     |  |                       |  |       inet:port-number
   |  |     |  |                       |  +--rw upper-port
   |  |     |  |                       |          inet:port-number
   |  |     |  |                       +--:(operator)
   |  |     |  |                          +--rw operator?   operator
   |  |     |  |                          +--rw port
   |  |     |  |                                  inet:port-number
   ...

                   Figure 26: QoS Subtree Structure (L4)

      Application match:  Relies upon application-specific
         classification.

   'carrierscarrier':  Groups a set of parameters that are used when CsC
      is enabled such the use of BGP for signalling purposes [RFC8277].

   'ntp':  Time synchronization may be needed in some VPNs such as
      infrastructure and management VPNs.  This container is used to
      enable the NTP service [RFC5905].

   'multicast':  Specifies the multicast mode and other data nodes such
      as the address-family.  Refer to Section 7.7.

7.7.  Multicast

   Multicast may be enabled for a particular VPN at the VPN node and VPN
   network access levels (see Figure 27).  Some data nodes (e.g., max-
   groups) can be controlled at various levels: VPN service, VPN node
   level, or VPN network access.

          ...
          +--rw vpn-services
             +--rw vpn-service* [vpn-id]
                ...
                +--rw vpn-instance-profiles
                |  +--rw vpn-instance-profile* [profile-id]
                |     ....
                |     +--rw multicast {vpn-common:multicast}?
                |        ...
                +--rw vpn-nodes
                   +--rw vpn-node* [vpn-node-id]
                      ...
                      +--rw active-vpn-instance-profiles
                      |  +--rw vpn-instance-profile* [profile-id]
                      |     ...
                      |     +--rw multicast {vpn-common:multicast}?
                      |        ...
                      +--rw vpn-network-accesses
                         +--rw vpn-network-access* [id]
                            ...
                            +--rw service
                               ...
                               +--rw multicast {vpn-common:multicast}?
                                  ...

              Figure 27: Overall Multicast Subtree Structure

   Multicast-related data nodes at the VPN instance profile level has
   the structure that is shown in Figure 30.

     ...
+--rw vpn-services
   +--rw vpn-service* [vpn-id]
      ...

      +--rw vpn-instance-profiles
      |  +--rw vpn-instance-profile* [profile-id]
      |     ....
      |     +--rw multicast {vpn-common:multicast}?
      |        +--rw tree-flavor*   identityref
      |        +--rw rp
      |        |  +--rw rp-group-mappings
      |        |  |  +--rw rp-group-mapping* [id]
      |        |  |     +--rw id                  uint16
      |        |  |     +--rw provider-managed
      |        |  |     |  +--rw enabled?                   boolean
      |        |  |     |  +--rw rp-redundancy?             boolean
      |        |  |     |  +--rw optimal-traffic-delivery?  boolean
      |        |  |     |  +--rw anycast
      |        |  |     |     +--rw local-address?    inet:ip-address
      |        |  |     |     +--rw rp-set-address*   inet:ip-address
      |        |  |     +--rw rp-address          inet:ip-address
      |        |  |     +--rw groups
      |        |  |        +--rw group* [id]
      |        |  |           +--rw id                     uint16
      |        |  |           +--rw (group-format)
      |        |  |              +--:(group-prefix)
      |        |  |              |  +--rw group-address?  inet:ip-prefix
      |        |  |              +--:(startend)
      |        |  |                 +--rw group-start?   inet:ip-address
      |        |  |                 +--rw group-end?     inet:ip-address
      |        |  +--rw rp-discovery
      |        |     +--rw rp-discovery-type?   identityref
      |        |     +--rw bsr-candidates
      |        |        +--rw bsr-candidate-address*   inet:ip-address
      |        +--rw igmp {vpn-common:igmp and vpn-common:ipv4}?
      |        |  +--rw static-group* [group-addr]
      |        |  |  +--rw group-addr
      |        |  |  |             rt-types:ipv4-multicast-group-address
      |        |  |  +--rw source-addr?
      |        |  |               rt-types:ipv4-multicast-source-address
      |        |  +--rw max-groups?     uint32
      |        |  +--rw max-entries?    uint32
      |        |  +--rw version?        identityref
      |        +--rw mld {vpn-common:mld and vpn-common:ipv6}?
      |        |  +--rw static-group* [group-addr]
      |        |  |  +--rw group-addr
      |        |  |  |             rt-types:ipv6-multicast-group-address
      |        |  |  +--rw source-addr?
      |        |  |               rt-types:ipv6-multicast-source-address
      |        |  +--rw max-groups?     uint32
      |        |  +--rw max-entries?    uint32
      |        |  +--rw version?        identityref
      |        +--rw pim {vpn-common:pim}?
      |           +--rw hello-interval?   rt-types:timer-value-seconds16
      |           +--rw dr-priority?      uint32
           ...

    Figure 28: Multicast Subtree Structure (VPN Instance Profile Level)

   The model supports a single type of tree: Any-Source Multicast (ASM),
   Source-Specific Multicast (SSM), or bidirectional.

   When ASM is used, the model supports the configuration of rendez-vous
   points (RPs).  RP discovery may be 'static', 'bsr-rp', or 'auto-rp'.
   When set to 'static', RP to multicast grouping mapping MUST be
   configured as part of the 'rp-group-mappings' container.  The RP MAY
   be a provider node or a customer node.  When the RP is a customer
   node, the RP address must be configured using the 'rp-address' leaf
   otherwise no RP address is needed.

   The model supports RP redundancy through the 'rp-redundancy' leaf.
   How the redundancy is achieved is out of scope and is up to the
   implementation.

   When a particular VPN using ASM requires a more optimal traffic
   delivery, 'optimal-traffic-delivery' can be set.  When set to 'true',
   the implementation must use any mechanism to provide a more optimal
   traffic delivery for the customer.  For example, anycast is one of
   the mechanisms to enhance RPs redundancy, resilience against
   failures, and to recover from failures quickly.

   The same structure as the one depicted in Figure 30 is used when
   configuring multicast-related parameters at the VPN node level.  When
   defined at the VPN node level (Figure 29), Internet Group Management
   Protocol (IGMP) [RFC1112][RFC2236][RFC3376], Multicast Listener
   Discovery (MLD) [RFC2710][RFC3810], and Protocol Independent
   Multicast (PIM) [RFC7761] parameters are applicable to all VPN
   network accesses of that VPN node unless corresponding nodes are
   refined at the VPN network access level.

     ...
     +--rw vpn-nodes
        +--rw vpn-node* [vpn-node-id]
           ...
           +--rw active-vpn-instance-profiles
           |  +--rw hello-interval?   uint8 vpn-instance-profile* [profile-id]
           |     ...
           |     +--rw dr-priority?      uint16 multicast {vpn-common:multicast}?
           |        +--rw status tree-flavor*   identityref
           |        +--rw admin-status rp
           |        |  ...
           |        +--rw status?         identityref igmp {vpn-common:igmp and vpn-common:ipv4}?
           |        |  ...
           |        +--rw last-updated?   yang:date-and-time mld {vpn-common:mld and vpn-common:ipv6}?
           |        +--ro oper-status        |           +--ro status?         identityref  ...
           |        +--rw pim {vpn-common:pim}?
           |           +--ro last-updated?   yang:date-and-time           ...

          Figure 28: 29: Multicast Subtree Structure (VPN Node Level)

   Multicast-related data nodes at the VPN network access level are
   shown in Figure 29.  Except the 'status' node, the value 30.  The values configured at the VPN network access
   level overrides override the value values configured for the corresponding data node at the VPN node level. nodes
   in other levels.

   ...
   +--rw vpn-network-accesses
      +--rw vpn-network-access* [id]
         ...
         +--rw service
            ...
            +--rw multicast {vpn-common:multicast}?
               +--rw access-type?      enumeration
               +--rw address-family?   identityref
               +--rw protocol-type?    enumeration
               +--rw remote-source?    boolean
               +--rw igmp  {vpn-common:igmp}?
               |  +--rw static-group* [group-addr]
               |  |  +--rw group-addr
               |  |         rt-types:ipv4-multicast-group-address
               |  |  +--rw source-addr?
               |  |         rt-types:ipv4-multicast-source-address
               |  +--rw max-groups?          uint32
               |  +--rw max-entries?         uint32
               |  +--rw max-group-sources?   uint32
               |  +--rw version?             identityref
               |  +--rw status
               |     +--rw admin-status
               |     |  +--rw status?         identityref
               |     |  +--rw last-updated?   yang:date-and-time
               |     +--ro oper-status
               |        +--ro status?         identityref
               |        +--ro last-updated?   yang:date-and-time
               +--rw mld {vpn-common:mld}?
               |  +--rw static-group* [group-addr]
               |  |  +--rw group-addr
               |  |         rt-types:ipv6-multicast-group-address
               |  |  +--rw source-addr?
               |  |         rt-types:ipv6-multicast-source-address
               |  +--rw max-groups?          uint32
               |  +--rw max-entries?         uint32
               |  +--rw max-group-sources?   uint32
               |  +--rw version?             identityref
               |  +--rw status
               |     +--rw admin-status
               |     |  +--rw status?         identityref
               |     |  +--rw last-updated?   yang:date-and-time
               |     +--ro oper-status
               |        +--ro status?         identityref
               |        +--ro last-updated?   yang:date-and-time
               +--rw pim {vpn-common:pim}?
                  +--rw priority?         uint8
                     +--rw hello-interval?   uint8   rt-types:timer-value-seconds16
                  +--rw dr-priority?      uint16      uint32
                  +--rw status
                     +--rw admin-status
                     |  +--rw status?         identityref
                     |  +--rw last-updated?   yang:date-and-time
                     +--ro oper-status
                        +--ro status?         identityref
                        +--ro last-updated?   yang:date-and-time

     Figure 29: Multicast Subtree Structure (VPN Network Access Level)

   The model supports a single type of tree: Any-Source Multicast (ASM),
   Source-Specific Multicast (SSM), or bidirectional.

   When ASM is used, the model supports the configuration of rendez-vous
   points (RPs).  RP discovery may be 'static', 'bsr-rp', or 'auto-rp'.
   When set to 'static', RP to multicast grouping mapping MUST be
   configured as part of the 'rp-group-mappings' container.  The RP MAY
   be a provider node or a customer node.  When the RP is a customer
   node, the RP address must be configured using the 'rp-address' leaf
   otherwise no RP address is needed.

   The model supports RP redundancy through the 'rp-redundancy' leaf.
   How the redundancy is achieved is out of scope and is up to the
   implementation.

   When a particular VPN using ASM requires a more optimal traffic
   delivery, 'optimal-traffic-delivery' can be set.  When set to 'true',
   the implementation must use any mechanism to provide a more optimal
   traffic delivery for the customer.  For example, anycast is one of
   the mechanisms to enhance RPs redundancy, resilience against
   failures, and to recover from failures quickly.

   For redundancy purposes,   yang:date-and-time

     Figure 30: Multicast Source Discovery Protocol (MSDP)
   [RFC3618] may be enabled and used to share the state about sources
   between multiple RPs.  The purpose of MSDP in this context is to
   enhance the robustness of the multicast service.  MSDP may be
   configured on non-RP routers, which is useful in a domain that does
   not support multicast sources, but does support multicast transit. Subtree Structure (VPN Network Access Level)

8.  L3NM YANG Module

   This module uses types defined in [RFC6991] and [RFC8343].  It also
   uses groupings defined in [RFC8519], [RFC8177], and [RFC8294].

<CODE BEGINS>  file "ietf-l3vpn-ntw@2021-02-19.yang" [RFC8294].

<CODE BEGINS>  file "ietf-l3vpn-ntw@2021-04-21.yang"
module ietf-l3vpn-ntw {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw";
  prefix l3nm;

  import ietf-vpn-common {
    prefix vpn-common;
    reference
      "RFC UUUU: A Layer 2/3 VPN Common YANG Model";
  }
  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-key-chain {
    prefix key-chain;
    reference
      "RFC 8177: YANG Key Chain.";
  }
  import ietf-routing-types {
    prefix rt-types;
    reference
      "RFC 8294: Common YANG Data Types for the Routing Area";
  }
  import ietf-interfaces {
    prefix if;
    reference
      "RFC 8343: A YANG Data Model for Interface Management";
  }

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

     Author:    Samier Barguil
                <mailto:samier.barguilgiraldo.ext@telefonica.com>
     Editor:    Oscar Gonzalez de Dios
                <mailto:oscar.gonzalezdedios@telefonica.com>
     Editor:    Mohamed Boucadair
                <mailto:mohamed.boucadair@orange.com>
     Author:    Luis Angel Munoz
                <mailto:luis-angel.munoz@vodafone.com>
     Author:    Alejandro Aguado
                <mailto:alejandro.aguado_martin@nokia.com>
    ";
  description
    "This YANG module defines a generic network-oriented model
     for the configuration of Layer 3 Virtual Private Networks.

     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 ietf-l3vpn-ntw {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw";
  prefix l3nm;

  import ietf-vpn-common is part of RFC XXXX; see
     the RFC itself for full legal notices.";

  revision 2021-04-21 {
    prefix vpn-common;
    description
      "Initial revision.";
    reference
      "RFC UUUU: XXXX: A Layer 2/3 3 VPN Common Network YANG Model";
  }
  import ietf-inet-types

  /* Features */

  feature msdp {
    prefix inet;
    description
      "This feature indicates that Multicast Source Discovery Protocol
       (MSDP) capabilities are supported by the VPN.";
    reference
      "Section 4 of RFC 6991";
      "RFC 3618: Multicast Source Discovery Protocol (MSDP)";
  }
  import ietf-yang-types

  /* Identities */

  identity address-allocation-type {
    prefix yang;
    description
      "Base identity for address allocation type in the
       Provider Edge (PE)-Customer Edge (CE) link.";
  }

  identity provider-dhcp {
    base address-allocation-type;
    description
      "The Provider's network provides a DHCP service to the customer.";
  }

  identity provider-dhcp-relay {
    base address-allocation-type;
    description
      "The Provider's network provides a DHCP relay service to the
       customer.";
  }

  identity provider-dhcp-slaac {
    if-feature "vpn-common:ipv6";
    base address-allocation-type;
    description
      "The Provider's network provides a DHCP service to the customer
       as well as IPv6 Stateless Address Autoconfiguration (SLAAC).";
    reference
      "Section 3 of RFC 6991";
      "RFC 4862: IPv6 Stateless Address Autoconfiguration";
  }
  import ietf-key-chain

  identity static-address {
    prefix key-chain;
    base address-allocation-type;
    description
      "The Provider-to-customer addressing is static.";
  }

  identity slaac {
    if-feature "vpn-common:ipv6";
    base address-allocation-type;
    description
      "Use IPv6 SLAAC.";
    reference
      "RFC 8177: YANG Key Chain."; 4862: IPv6 Stateless Address Autoconfiguration";
  }
  import ietf-routing-types

  identity bearer-inf-type {
    description
      "Identity for the bearer interface type.";
  }

  identity port-id {
    base bearer-inf-type;
    description
      "Identity for the priority-tagged interface.";
  }

  identity lag-id {
    prefix rt-types;
    reference
      "RFC 8294: Common YANG Data Types
    base bearer-inf-type;
    description
      "Identity for the Routing Area"; lag-tagged interface.";
  }

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

     Editor:    Samier Barguil
                <mailto:samier.barguilgiraldo.ext@telefonica.com>
     Editor:    Oscar Gonzalez de Dios
                <mailto:oscar.gonzalezdedios@telefonica.com>
     Editor:    Mohamed Boucadair
                <mailto:mohamed.boucadair@orange.com>
     Author:    Luis Angel Munoz
                <mailto:luis-angel.munoz@vodafone.com>
     Author:    Alejandro Aguado
                <mailto:alejandro.aguado_martin@nokia.com>
    ";

  identity local-defined-next-hop {
    description
    "This YANG module defines
      "Defines a generic network-oriented model base identity type of local defined
       next-hops.";
  }

  identity discard {
    base local-defined-next-hop;
    description
      "Indicates an action to discard traffic for the configuration of Layer 3 Virtual Private Networks.

     Copyright (c) 2021 IETF Trust and
       corresponding destination.
       For example, this can be used to blackhole traffic.";
  }

  identity local-link {
    base local-defined-next-hop;
    description
      "Treat traffic towards addresses within the persons identified specified next-hop
       prefix 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 though they are connected to a local link.";
  }

  identity l2-tunnel-type {
    description
      "Base identity for layer-2 tunnel selection under the license terms contained in, the Simplified BSD License set
     forth VPN
       network access.";
  }

  identity pseudowire {
    base l2-tunnel-type;
    description
      "Pseudowire tunnel termination in Section 4 of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX
     (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
     for full legal notices.";

  revision 2021-02-19 VPN network access.";
  }

  identity vpls {
    base l2-tunnel-type;
    description
      "Initial revision.";
    reference
      "RFC XXXX: A Layer 3
      "Virtual Private LAN Service (VPLS) tunnel termination in
       the VPN network access.";
  }

  identity vxlan {
    base l2-tunnel-type;
    description
      "Virtual eXtensible Local Area Network YANG Model"; (VXLAN) tunnel
       termination in the VPN network access.";
  }

  /* Features Typedefs */

  feature msdp
  typedef predefined-next-hop {
    type identityref {
      base local-defined-next-hop;
    }
    description
      "Pre-defined next-hop designation for locally generated routes.";
  }

  typedef area-address {
    type string {
      pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}';
    }
    description
      "This feature indicates that Multicast Source Discovery Protocol
       (MSDP) capabilities are supported by type defines the VPN.";
    reference
      "RFC 3618: Multicast Source Discovery Protocol (MSDP)"; area address format.";
  }

  /* Identities Groupings */

  identity address-allocation-type

  grouping vpn-instance-profile {
    description
      "Base identity
      "Grouping for address allocation data nodes that may be factorized
       among many levels of the model. The grouping can
       be used to define generic profiles at the VPN service
       level and then called at the VPN node and VPN network
       access levels.";
    leaf local-autonomous-system {
      if-feature "vpn-common:rtg-bgp";
      type inet:as-number;
      description
        "Provider's AS number in case the
       Provider Edge (PE)-Customer Edge (CE) link."; customer requests BGP
         routing.";
    }

  identity provider-dhcp
    uses vpn-common:route-distinguisher;
    list address-family {
      key "address-family";
      description
        "Set of per-address family paramters.";
      leaf address-family {
        type identityref {
          base address-allocation-type; vpn-common:address-family;
        }
        description
      "The Provider's network provides a DHCP service to
          "Indicates the customer."; address family (IPv4 or IPv6).";
      }

  identity provider-dhcp-relay
      container vpn-targets {
    base address-allocation-type;
        description
      "The Provider's network provides a DHCP relay service
          "Set of route targets to the
       customer."; match for import and export routes
           to/from VRF.";

        uses vpn-common:vpn-route-targets;
      }

  identity provider-dhcp-slaac
      list maximum-routes {
        key "protocol";
        description
          "Defines maximum routes for the VRF.";
        leaf protocol {
          type identityref {
            base address-allocation-type; vpn-common:routing-protocol-type;
          }
          description
      "The Provider's network provides a DHCP service to
            "Indicates the customer
       as well as IPv6 Stateless Address Autoconfiguration (SLAAC).";
    reference
      "RFC 7527: IPv6 Stateless Address Autoconfiguration"; routing protocol. 'any' value can
             be used to identify a limit that will apply for
             each active routing protocol.";
        }

  identity static-address
        leaf maximum-routes {
    base address-allocation-type;
          type uint32;
          description
      "The Provider-to-customer addressing is static.";
            "Indicates the maximum prefixes the VRF can accept
             for this address family and protocol.";
        }

  identity slaac
      }
    }
    container multicast {
      if-feature "vpn-common:ipv6"; "vpn-common:multicast";
      description
        "Global multicast parameters.";
      leaf-list tree-flavor {
        type identityref {
          base address-allocation-type; vpn-common:multicast-tree-type;
        }
        description
      "Use IPv6 SLAAC.";
    reference
      "RFC 7527: IPv6 Stateless Address Autoconfiguration";
          "Type of tree to be used.";
      }

  identity bearer-inf-type
      container rp {
        description
      "Identity
          "RP parameters.";
        container rp-group-mappings {
          description
            "RP-to-group mappings parameters.";
          list rp-group-mapping {
            key "id";
            description
              "List of RP-to-group mappings.";
            leaf id {
              type uint16;
              description
                "Unique identifier for the bearer interface type."; mapping.";

            }

  identity port-id
            container provider-managed {
    base bearer-inf-type;
              description
      "Identity
                "Parameters for a provider-managed RP.";
              leaf enabled {
                type boolean;
                default "false";
                description
                  "Set to true if the priority-tagged interface."; Rendezvous Point (RP)
                   must be a provider-managed node.  Set to
                   false if it is a customer-managed node.";
              }

  identity lag-id
              leaf rp-redundancy {
    base bearer-inf-type;
                type boolean;
                default "false";
                description
      "Identity
                  "If true, a redundancy mechanism for the lag-tagged interface.";
                   RP is required.";
              }

  identity local-defined-next-hop
              leaf optimal-traffic-delivery {
    description
      "Defines a base identity
                type of local defined
       next-hops."; boolean;
                default "false";
                description
                  "If true, the SP must ensure that
                   traffic uses an optimal path.  An SP may
                   use Anycast RP or RP-tree-to-SPT
                   switchover architectures.";
              }

  identity discard
              container anycast {
                when "../rp-redundancy = 'true' and
                      ../optimal-traffic-delivery = 'true'" {
    base local-defined-next-hop;
                  description
      "Indicates an action to discard traffic for the
       corresponding destination.
       For example, this can be used to blackhole traffic.";
                    "Only applicable if RP redundancy is enabled
                     and delivery through optimal path is
                     activated.";
                }

  identity local-link
                description
                  "PIM Anycast-RP parameters.";
                leaf local-address {
    base local-defined-next-hop;
                  type inet:ip-address;
                  description
      "Treat traffic towards addresses within the specified next-hop
       prefix as though they are connected to a
                    "IP local link."; address for PIM RP. Usually, it
                     corresponds to router ID or primary
                     address";
                }

  typedef predefined-next-hop
                leaf-list rp-set-address {
                  type identityref {
      base local-defined-next-hop;

    } inet:ip-address;
                  description
      "Pre-defined next-hop designation for locally generated routes.";
                    "Address other RP routers that share the
                     same RP IP address.";
                }

  /* Typedefs */

  typedef area-address
              }
            }
            leaf rp-address {
    type string
              when "../provider-managed/enabled = 'false'" {
      pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}';
    }
                description
      "This
                  "Relevant when the RP is not
                   provider-managed.";
              }
              type defines inet:ip-address;
              mandatory true;
              description
                "Defines the area address format."; of the RP.
                 Used if the RP is customer-managed.";
            }

  /* Main Blocks */
  /* Main l3vpn-ntw */
            container l3vpn-ntw groups {
              description
      "Main container for L3VPN services management.";
    container vpn-profiles
                "Multicast groups associated with the RP.";
              list group {
                key "id";
                description
        "Contains a set
                  "List of valid VPN Profiles to reference in multicast groups.";
                leaf id {
                  type uint16;
                  description
                    "Identifier for the VPN
         service.";
      uses vpn-common:vpn-profile-cfg; group.";
                }
    container vpn-services
                choice group-format {
                  mandatory true;
                  description
        "Top-level container
                    "Choice for the VPN services.";
      list vpn-service multicast group format.";
                  case group-prefix {
        key "vpn-id";
                    leaf group-address {
                      type inet:ip-prefix;
                      description
          "List of VPN services.";
        uses vpn-common:vpn-description;
                        "A single multicast group prefix.";
                    }
                  }
                  case startend {
                    leaf parent-service-id group-start {
                      type vpn-common:vpn-id; inet:ip-address;
                      description
            "Pointer to
                        "The first multicast group address in
                         the parent service, if any.
             A parent service can an L3SM, a slice request, a VPN+
             service, etc."; multicast group address range.";
                    }
                    leaf group-end {
                      type inet:ip-address;
                      description
                        "The last multicast group address in
                         the multicast group address range.";
                    }
                  }
                }
              }
            }
        leaf vpn-type {
          type identityref {
            base vpn-common:service-type;
          }
          description
            "Indicates the service type.";
        }
        container rp-discovery {
          description
            "RP discovery parameters.";
          leaf vpn-service-topology rp-discovery-type {
            type identityref {
              base vpn-common:vpn-topology; vpn-common:multicast-rp-discovery-type;
            }
            default "vpn-common:any-to-any"; "vpn-common:static-rp";
            description
            "VPN service topology.";
              "Type of RP discovery used.";
          }
        uses vpn-common:service-status;
          container ie-profiles bsr-candidates {
          description
            "Container for Import/Export profiles.";
          list ie-profile
            when "derived-from-or-self(../rp-discovery-type, "
               + "'vpn-common:bsr-rp')" {
            key "ie-profile-id";
              description
              "List for Imort/Export profile.";
            leaf ie-profile-id {
                "Only applicable if discovery type string;
              description
                "IE profile id.";
            }
            uses vpn-common:rt-rd;
          }
        }
        container underlay-transport {
          description
            "Container for underlay transport.";
          uses vpn-common:underlay-transport; is BSR-RP.";
            }
        container external-connectivity {
          if-feature "vpn-common:external-connectivity";
            description
              "Container for external connectivity.";
          choice profile {
            description
              "Choice for the external connectivity profile.";
            case profile {
              leaf profile-name List of Customer BSR candidate's
               addresses.";
            leaf-list bsr-candidate-address {
              type leafref {
                  path "/l3vpn-ntw/vpn-profiles"
                     + "/valid-provider-identifiers"
                     + "/external-connectivity-identifier/id";
                } inet:ip-address;
              description
                  "Name of the service provider's profile to be applied
                   at
                "Specifies the VPN service level."; address of candidate Bootstrap
                 Router (BSR).";
            }
          }
        }
      }
      container vpn-nodes igmp {
        if-feature "vpn-common:igmp and vpn-common:ipv4";
        description
            "Container for VPN nodes.";
          "Includes IGMP-related parameters.";
        list vpn-node static-group {
          key "vpn-node-id"; "group-addr";
          description
              "List for VPN node.";
            "Multicast static source/group associated to the
             IGMP session";
          leaf vpn-node-id {
              type union group-addr {
            type vpn-common:vpn-id;
                type uint32;
              } rt-types:ipv4-multicast-group-address;
            description
                "Type STRING or NUMBER identifier.";
              "Multicast group IPv4 addresss.";
          }
          leaf description source-addr {
            type string;
              description
                "Textual rt-types:ipv4-multicast-source-address;
            description of the VPN node.";
              "Multicast source IPv4 addresss.";
          }
            leaf ne-id {
              type string;
              description
                "Unique identifier of the network element where the VPN
                 node is deployed.";
        }
        leaf node-role max-groups {
          type identityref {
                base vpn-common:role;
              }
              default "vpn-common:any-to-any-role"; uint32;
          description
                "Role of the VPN node in
            "Indicates the IP VPN."; maximum groups.";
        }
        leaf local-autonomous-system max-entries {
              if-feature "vpn-common:rtg-bgp";
          type inet:as-number; uint32;
          description
                "Provider's AS number in case
            "Indicates the customer requests BGP
                 routing."; maximum IGMP entries.";
        }
        leaf address-family version {
          type identityref {
            base vpn-common:address-family; vpn-common:igmp-version;
          }
          default "vpn-common:igmpv2";
          description
                "The address family used
            "Version of the IGMP.";
          reference
            "RFC 1112: Host Extensions for router-id information."; IP Multicasting
             RFC 2236: Internet Group Management Protocol, Version 2
             RFC 3376: Internet Group Management Protocol, Version 3";
        }
      }
      container mld {
        if-feature "vpn-common:mld and vpn-common:ipv6";
        description
          "Includes MLD-related parameters.";
        list static-group {
          key "group-addr";
          description
            "Multicast static source/group associated to the
             MLD session";
          leaf router-id group-addr {
            type inet:ip-address; rt-types:ipv6-multicast-group-address;
            description
                "The router-id information can be an IPv4 or
              "Multicast group IPv6
                 address."; addresss.";

          }
            uses vpn-common:rt-rd;
          leaf node-ie-profile source-addr {
            type leafref {
                path "/l3vpn-ntw/vpn-services/vpn-service"
                   + "/ie-profiles/ie-profile/ie-profile-id";
              } rt-types:ipv6-multicast-source-address;
            description
                "Node's Import/Export profile.";
              "Multicast source IPv6 addresss.";
          }
            container maximum-routes
        }
        leaf max-groups {
          type uint32;
          description
                "Defines maximum routes for
            "Indicates the VRF.";
              list selector {
                key "address-family protocol";
                description
                  "List of address families."; maximum groups.";
        }
        leaf address-family max-entries {
          type identityref {
                    base vpn-common:address-family;
                  } uint32;
          description
            "Indicates the address family (IPv4 or IPv6)."; maximum MLD entries.";
        }
        leaf protocol version {
          type identityref {
            base vpn-common:routing-protocol-type; vpn-common:mld-version;
          }
          default "vpn-common:mldv2";
          description
                    "Indicates
            "Version of the routing protocol. 'any' value can
                     be used to identify a limit that will apply for
                     any active routing MLD protocol.";
          reference
            "RFC 2710: Multicast Listener Discovery (MLD) for IPv6
             RFC 3810: Multicast Listener Discovery Version 2 (MLDv2)
                       for IPv6";
        }
      }
      container pim {
        if-feature "vpn-common:pim";
        description
          "Only applies when protocol type is PIM.";
        leaf maximum-routes hello-interval {
          type rt-types:timer-value-seconds16;
          default "30";
          description
            "PIM hello-messages interval. If set to
             'infinity' or 'not-set', no periodic
             Hello messages are sent.";
          reference
            "RFC 7761: Protocol Independent Multicast - Sparse
                       Mode (PIM-SM): Protocol Specification (Revised),
                       Section 4.11";
        }
        leaf dr-priority {
          type uint32;
          default "1";
          description
            "Indicates the maximum prefixes preference in the VRF can accept
                     for this address family and protocol."; DR election
             process. Numerically larger DR priority allows
             a node to be elected as a DR.";
          reference
            "RFC 7761: Protocol Independent Multicast - Sparse
                       Mode (PIM-SM): Protocol Specification (Revised),
                       Section 4.3.2";
        }
      }
    }
            uses vpn-common:vpn-components-group;
  }

  /* Main Blocks */
  /* Main l3vpn-ntw */

  container multicast l3vpn-ntw {
              if-feature "vpn-common:multicast";
    description
                "Global multicast parameters.";
              uses vpn-common:service-status;
              leaf-list tree-flavor {
                type identityref
      "Main container for L3VPN services management.";
    container vpn-profiles {
                  base vpn-common:multicast-tree-type;
                }
      description
                  "Type
        "Contains a set of tree valid VPN Profiles to be used."; reference in the VPN
         service.";
      uses vpn-common:vpn-profile-cfg;
    }
    container rp vpn-services {
      description
                  "RP parameters.";
        "Top-level container rp-group-mappings {
                  description
                    "RP-to-group mappings parameters."; for the VPN services.";
      list rp-group-mapping vpn-service {
        key "id"; "vpn-id";
        description
          "List of RP-to-group mappings.";
                    leaf id {
                      type uint16;
                      description
                        "Unique identifier for the mapping.";
                    }
                    container provider-managed {
                      description
                        "Parameters for a provider-managed RP."; VPN services.";
        uses vpn-common:vpn-description;
        leaf enabled parent-service-id {
          type boolean;
                        default "false"; vpn-common:vpn-id;
          description
                          "Set
            "Pointer to true if the Rendezvous Point (RP)
                           must parent service, if any.
             A parent service can be an L3SM, a provider-managed node.  Set to
                           false if it is slice request, a customer-managed node."; VPN+
             service, etc.";
        }
        leaf rp-redundancy vpn-type {
          type boolean;
                        default "false"; identityref {
            base vpn-common:service-type;
          }
          description
                          "If true, a redundancy mechanism for
            "Indicates the
                           RP is required."; service type.";
        }
        leaf optimal-traffic-delivery vpn-service-topology {
          type boolean; identityref {
            base vpn-common:vpn-topology;
          }
          default "false"; "vpn-common:any-to-any";
          description
                          "If true, the SP must ensure that
                           traffic uses an optimal path.  An SP may
                           use Anycast RP or RP-tree-to-SPT
                           switchover architectures.";
            "VPN service topology.";
        }
        uses vpn-common:service-status;
        container anycast {
                        when "../rp-redundancy = 'true' and
                              ../optimal-traffic-delivery = 'true'" vpn-instance-profiles {
          description
                            "Only applicable if RP redundancy is enabled
                             and delivery through optimal path is
                             activated.";
                        }
            "Container for a list of VPN instance profiles.";
          list vpn-instance-profile {
            key "profile-id";
            description
                          "PIM Anycast-RP parameters.";
              "List of VPN instance profiles.";
            leaf local-address profile-id {
              type inet:ip-address; string;
              description
                            "IP local address for PIM RP. Usually, it
                             corresponds to router ID or primary
                             address";
                "VPN instance profile identifier.";
            }
                        leaf-list rp-set-address
            leaf role {
              type inet:ip-address; identityref {
                base vpn-common:role;
              }
              default "vpn-common:any-to-any-role";
              description
                            "Address other RP routers that share
                "Role of the VPN node in the
                             same RP IP address."; VPN.";
            }
            uses vpn-instance-profile;
          }
        }
                    leaf rp-address
        container underlay-transport {
                      when "../provider-managed/enabled = 'false'"
          description
            "Container for underlay transport.";
          uses vpn-common:underlay-transport;
        }
        container external-connectivity {
          if-feature "vpn-common:external-connectivity";
          description
                          "Relevant when
            "Container for external connectivity.";
          choice profile {
            description
              "Choice for the RP is not
                           provider-managed.";
                      } external connectivity profile.";
            case profile {
              leaf profile-name {
                type inet:ip-address;
                      mandatory true; leafref {
                  path "/l3vpn-ntw/vpn-profiles"
                     + "/valid-provider-identifiers"
                     + "/external-connectivity-identifier/id";
                }
                description
                        "Defines the address
                  "Name of the RP.
                         Used if service provider's profile to be applied
                   at the RP is customer-managed."; VPN service level.";
              }
            }
          }
        }
        container groups vpn-nodes {
          description
                        "Multicast groups associated with the RP.";
            "Container for VPN nodes.";
          list group vpn-node {
            key "id"; "vpn-node-id";
            description
              "List of multicast groups."; for VPN node.";
            leaf id vpn-node-id {
              type uint16; vpn-common:vpn-id;
              description
                            "Identifier for
                "An identifier of the group."; VPN node.";
            }
                        choice group-format {
                          mandatory true;
            leaf description
                            "Choice for multicast group format.";
                          case group-prefix {
              type string;
              description
                "Textual description of the VPN node.";
            }
            leaf group-address ne-id {
              type inet:ip-prefix; string;
              description
                                "A single multicast group prefix.";
                            }
                "Unique identifier of the network element where the VPN
                 node is deployed.";
            }
                          case startend {
            leaf group-start local-autonomous-system {
              if-feature "vpn-common:rtg-bgp";
              type inet:ip-address; inet:as-number;
              description
                                "The first multicast group address
                "Provider's AS number in case the multicast group address range."; customer requests BGP
                 routing.";
            }
            leaf group-end router-id {
              type inet:ip-address; rt-types:router-id;
              description
                                "The last multicast group address
                "A 32-bit number in the multicast group address range.";
                            }
                          }
                        }
                      }
                    }
                  } dotted-quad format that is used
                 to uniquely identify a node within an autonomous
                 system. This identifier is used for both IPv4 and
                 IPv6.";
            }
            container rp-discovery active-vpn-instance-profiles {
              description
                "Container for active VPN instance profiles.";
              list vpn-instance-profile {
                key "profile-id";
                description
                    "RP discovery parameters.";
                  "";
                leaf rp-discovery-type profile-id {
                  type identityref leafref {
                      base vpn-common:multicast-rp-discovery-type;
                    path "/l3vpn-ntw/vpn-services/vpn-service"
                       + "/vpn-instance-profiles/vpn-instance-profile"
                       + "/profile-id";
                  }
                    default "vpn-common:static-rp";
                  description
                      "Type of RP discovery used.";
                    "Node's Import/Export profile.";
                }
                  container bsr-candidates {
                    when "derived-from-or-self(../rp-discovery-type, "
                       + "'vpn-common:bsr-rp')"
                list router-id {
                  key "address-family";
                  description
                        "Only applicable if discovery
                    "Router-id per address family.";
                  leaf address-family {
                    type is BSR-RP."; identityref {
                      base vpn-common:address-family;
                    }
                    description
                      "Container for List of Customer BSR candidate's
                       addresses.";
                    leaf-list bsr-candidate-address
                      "Indicates the address family (IPv4 or IPv6).";
                  }
                  leaf router-id {
                    type inet:ip-address;
                    description
                        "Specifies the
                      "The router-id information can be an IPv4 or IPv6
                       address. This can be used, for example, to
                       configure an IPv6 address of candidate Bootstrap
                         Router (BSR)."; as a router-id
                       when such capability is supported by underlay
                       routers. In such case, the configured value
                       overrides the generic one defined at the VPN
                       node level.";
                  }
                }
                uses vpn-instance-profile;
              }
            }
            container msdp {
              if-feature "msdp";
              description
                "Includes MSDP-related parameters.";
              leaf peer {
                type inet:ip-address;
                description
                  "Indicates the IP address of the MSDP peer.";
              }
              leaf local-address {
                type inet:ip-address;
                description
                  "Indicates the IP address of the local end.
                   This local address must be configured on
                   the node.";
              }
              uses vpn-common:service-status;
            }
            uses vpn-common:vpn-components-group;
            uses vpn-common:service-status;
            container igmp vpn-network-accesses {
                if-feature "vpn-common:igmp and vpn-common:ipv4";
              description
                  "Includes IGMP-related parameters.";
                "List of network accesses.";
              list static-group vpn-network-access {
                key "group-addr"; "id";
                description
                    "Multicast static source/group associated to the
                     IGMP session";
                  "List of network accesses.";
                leaf group-addr id {
                  type rt-types:ipv4-multicast-group-address; vpn-common:vpn-id;
                  description
                      "Multicast group IPv4 addresss.";
                    "Identifier for the network access.";
                }
                leaf source-addr port-id {
                  type rt-types:ipv4-multicast-source-address; vpn-common:vpn-id;
                  description
                      "Multicast source IPv4 addresss.";
                    "Identifier for the interface.";
                }
                leaf description {
                  type string;
                  description
                    "Textual description of the network access.";
                }
                leaf max-groups vpn-network-access-type {
                  type uint32; identityref {
                    base vpn-common:site-network-access-type;
                  }
                  default "vpn-common:point-to-point";
                  description
                    "Indicates
                    "Describes the maximum groups."; type of connection, e.g.,
                     point-to-point.";
                }
                leaf max-entries vpn-instance-profile {
                  type leafref {
                    path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes"
                       + "/vpn-node/active-vpn-instance-profiles"
                       + "/vpn-instance-profile/profile-id";
                  }
                  description
                    "An identifier of an active VPN instance profile.";
                }
                uses vpn-common:service-status;
                container connection {
                  description
                    "Defines layer 2 protocols and parameters that are
                     required to enable connectivity between the PE
                     and the CE.";
                  container encapsulation {
                  type uint32;
                    description
                    "Indicates the maximum IGMP entries.";
                }
                      "Container for layer 2 encapsulation.";
                    leaf version type {
                      type identityref {
                        base vpn-common:igmp-version; vpn-common:encapsulation-type;
                      }
                      default "vpn-common:igmpv2"; "vpn-common:priority-tagged";
                      description
                    "Version
                        "Tagged interface type. By default, the type of
                         the IGMP.";
                }
                uses vpn-common:service-status; tagged interface is 'priority-tagged'.";
                    }
                    container mld dot1q {
                if-feature "vpn-common:mld and vpn-common:ipv6";
                description
                  "Includes MLD-related parameters.";
                list static-group
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:dot1q')" {
                  key "group-addr";
                        description
                    "Multicast static source/group associated to
                          "Only applies when the
                     MLD session"; type of the
                           tagged interface is 'dot1q'.";
                      }
                      if-feature "vpn-common:dot1q";
                      description
                        "Tagged interface.";
                      leaf group-addr tag-type {
                        type rt-types:ipv6-multicast-group-address; identityref {
                          base vpn-common:tag-type;
                        }
                        default "vpn-common:c-vlan";
                        description
                      "Multicast group IPv6 addresss.";
                          "Tag type. By default, the tag type is
                           'c-vlan'.";
                      }
                      leaf source-addr cvlan-id {
                        type rt-types:ipv6-multicast-source-address; uint16;
                        description
                      "Multicast source IPv6 addresss.";
                          "VLAN identifier.";
                      }

                    }
                leaf max-groups
                    container priority-tagged {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:priority-tagged')" {
                  type uint32;
                        description
                    "Indicates
                          "Only applies when the maximum groups.";
                }
                leaf max-entries { type uint32;
                  description
                    "Indicates of the maximum MLD entries.";
                           tagged interface is 'priority-tagged'.";
                      }
                      description
                        "Priority tagged.";
                      leaf version tag-type {
                        type identityref {
                          base vpn-common:mld-version; vpn-common:tag-type;
                        }
                        default "vpn-common:mldv2"; "vpn-common:c-vlan";
                        description
                    "Version of
                          "Tag type. By default, the MLD protocol."; tag type is
                           'c-vlan'.";
                      }
                uses vpn-common:service-status;
                    }
                    container pim qinq {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:qinq')" {
                if-feature "vpn-common:pim";
                        description
                          "Only applies when protocol the type of the tagged
                           interface is PIM."; QinQ.";
                      }
                      if-feature "vpn-common:qinq";
                      description
                        "Includes QinQ parameters.";
                      leaf hello-interval tag-type {
                        type uint8;
                  units "seconds"; identityref {
                          base vpn-common:tag-type;
                        }
                        default "30"; "vpn-common:c-s-vlan";
                        description
                    "PIM hello-messages interval.";
                          "Tag type. By default, the tag type is
                           'c-s-vlan'.";
                      }
                      leaf svlan-id {
                        type uint16;
                        mandatory true;
                        description
                          "SVLAN identifier.";
                      }
                      leaf cvlan-id {
                        type uint16;
                        mandatory true;
                        description
                          "CVLAN identifier.";
                      }
                    }
                  }
                  container l2-tunnel-service {
                    description
                      "Defines a layer 2 tunnel termination.
                       It is only applicable when a tunnel is
                       required. The supported values are:
                       pseudowire, VPLS and, VXLAN. Other
                       values may defined, if needed.";
                    leaf dr-priority type {
                      type uint16; identityref {
                        base l2-tunnel-type;
                      }
                      description
                    "Value to increase or decrease
                        "Selects the
                     chances of a given DR being elected.";
                }
                uses vpn-common:service-status;
              } tunnel termiantion option for
                         each vpn-network-access.";
                    }
            uses vpn-common:service-status;
                    container vpn-network-accesses {
              description
                "List of network accesses.";
              list vpn-network-access pseudowire {
                key "id";
                      description
                  "List of network accesses.";
                        "Includes pseudowire termination parameters.";
                      leaf id vcid {
                        type vpn-common:vpn-id; uint32;
                        description
                    "Identifier for the network access.";
                          "Indicates a PW or VC identifier.";
                      }
                      leaf port-id far-end {
                        type vpn-common:vpn-id; union {
                          type uint32;
                          type inet:ip-address;
                        }
                        description
                    "Identifier for the interface.";
                          "SDP/Far End/LDP neighbour reference.";
                      }
                leaf
                    }
                    container vpls {
                      description
                        "VPLS termination parameters.";
                      leaf vcid {
                        type union {
                          type uint32;
                          type string;
                        }
                        description
                    "Textual description of the network access.";
                          "VCID identifier, IRB/RVPPLs interface
                           supported using string format.";

                      }
                      leaf vpn-network-access-type far-end {
                        type identityref union {
                    base vpn-common:site-network-access-type;
                          type uint32;
                          type inet:ip-address;
                        }
                  default "vpn-common:point-to-point";
                        description
                    "Describes the type of connection, e.g.,
                     point-to-point or multipoint.";
                          "SDP/Far End/LDP neighbour reference.";
                      }
                    }
                uses vpn-common:service-status;
                    container connection vxlan {
                      if-feature "vpn-common:vxlan";
                      description
                        "VXLAN termination parameters.";
                      leaf vni-id {
                        type uint32;
                        mandatory true;
                        description
                    "Encapsulation types.";
                          "VXLAN Network Identifier (VNI).";
                      }
                      leaf encapsulation-type peer-mode {
                        type identityref {
                          base vpn-common:encapsulation-type; vpn-common:vxlan-peer-mode;
                        }
                        default "vpn-common:untagged-int"; "vpn-common:static-mode";
                        description
                      "Encapsulation type.
                          "Specifies the VXLAN access mode. By default,
                           the encapsulation
                       type peer mode is set to 'untagged'."; 'static-mode'.";
                      }
                  container logical-interface
                      leaf-list peer-ip-address {
                        type inet:ip-address;
                        description
                      "Reference
                          "List of peer's IP addresses.";
                      }
                    }
                  }
                  leaf l2-termination-point {
                    type vpn-common:vpn-id;
                    description
                      "Specifies a logical interface
                       type."; reference to a local layer 2
                       termination point such a layer 2 sub-interface.";
                  }
                  leaf peer-reference local-bridge-reference {
                    type uint32; vpn-common:vpn-id;
                    description
                      "Specifies a local bridge reference to
                       accommodate, for example, implementations
                       that require internal bridging.

                       A reference may be a local bridge domain.";
                  }
                  leaf l2vpn-id {
                    type vpn-common:vpn-id;
                    description
                      "Indicates the L2VPN service associated with an
                       Integrated Routing and Bridging (IRB)
                       interface.";
                  }
                  leaf bearer-reference {
                    if-feature "vpn-common:bearer-reference";
                    type string;
                    description
                      "This is an internal reference for the associated logical peer
                         interface."; service
                       provider.";
                  }
                }
                container tagged-interface ip-connection {
                  description
                      "Container for tagged interfaces.";
                    "Defines IP connection parameters.";
                  leaf type l3-termination-point {
                    type identityref {
                        base vpn-common:encapsulation-type;
                      }
                      default "vpn-common:priority-tagged"; vpn-common:vpn-id;
                    description
                        "Tagged interface type. By default, the type of
                         the tagged interface is 'priority-tagged'.";
                      "Specifies a reference to a local layer 3
                       termination point such as a bridge domain
                       interface.";
                  }
                  container dot1q-vlan-tagged {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:dot1q')" ipv4 {
                    if-feature "vpn-common:ipv4";
                    description
                          "Only applies when the
                      "IPv4-specific parameters.";
                    leaf local-address {
                      type of the
                           tagged interface inet:ipv4-address;
                      description
                        "This address is 'dot1q'."; used at the provider side.";
                    }
                      if-feature "vpn-common:dot1q";
                      description
                        "Tagged interface.";
                    leaf tag-type prefix-length {
                      type identityref uint8 {
                          base vpn-common:tag-type;
                        range "0..32";
                      }
                        default "vpn-common:c-vlan";
                      description
                          "Tag type. By default, the tag type
                        "Subnet prefix length expressed in bits.
                         It is
                           'c-vlan'."; applied to both local and customer
                         addresses.";
                    }
                    leaf cvlan-id address-allocation-type {
                      type uint16;
                        description
                          "VLAN identifier.";
                      }
                    }
                    container priority-tagged identityref {
                      when "derived-from-or-self(../type,
                        base address-allocation-type;

                      }
                      must "not(derived-from-or-self(current(), "
                         + "'vpn-common:priority-tagged')" "'slaac') or derived-from-or-self(current(),"
                         + " 'provider-dhcp-slaac'))" {
                        error-message
                          "SLAAC is only applicable to IPv6.";
                      }
                      description
                          "Only applies when
                        "Defines how addresses are allocated to the type of
                         peer site.

                         If there is no value for the
                           tagged interface address
                         allocation type, then IPv4 addressing is 'priority-tagged'."; not
                         enabled.";
                    }
                      description
                        "Priority tagged.";

                      leaf tag-type {
                        type identityref
                    choice allocation-type {
                          base vpn-common:tag-type;
                        }
                        default "vpn-common:c-vlan";
                      description
                          "Tag type. By default,
                        "Choice of the tag type is
                           'c-vlan'.";
                      }
                    }
                    container qinq IPv4 address allocation.";
                      case provider-dhcp {
                        when "derived-from-or-self(../type, " "derived-from-or-self(./address-"
                           + "'vpn-common:qinq')" "allocation-type, 'provider-dhcp')" {
                          description
                            "Only applies when the type of the tagged
                           interface is 'qinq'.";
                      }
                      if-feature "vpn-common:qinq";
                      description
                        "QinQ.";
                      leaf tag-type {
                        type identityref {
                          base vpn-common:tag-type;
                        }
                        default "vpn-common:c-s-vlan";
                        description
                          "Tag type. By default, the tag type addresses are allocated
                             by DHCP that is
                           'c-s-vlan'."; operated by the provider.";
                        }
                        description
                          "DHCP allocated addresses related
                           parameters.";
                        leaf svlan-id dhcp-service-type {
                          type uint16;
                        mandatory true; enumeration {
                            enum server {
                              description
                          "SVLAN identifier.";
                                "Local DHCP server.";
                            }
                      leaf cvlan-id
                            enum relay {
                        type uint16;
                        mandatory true;
                              description
                          "CVLAN identifier.";
                                "Local DHCP relay. DHCP requests are
                                 relayed to a provider's server.";
                            }
                          }
                    container qinany {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:qinany')" {
                          description
                          "Only applies when
                            "Indicates the type of the
                           tagged interface is 'qinany'."; DHCP service to
                             be enabled on this access.";
                        }
                      if-feature "vpn-common:qinany";
                        choice service-type {
                          description
                            "Choice based on the DHCP service type.";
                          case relay {
                            when "./dhcp-service-type = 'relay'";
                            description
                              "Container for QinAny.";
                      leaf tag-type list of provider's DHCP
                               servers.";
                            leaf-list server-ip-address {
                              type identityref {
                          base vpn-common:tag-type;
                        }
                        default "vpn-common:s-vlan"; inet:ipv4-address;
                              description
                          "Tag type. By default,
                                "IPv4 addresses of the tag type is
                           's-vlan'."; provider's DHCP
                                 server to use by the local DHCP
                                 relay.";
                            }
                          }
                          case server {
                            when "./dhcp-service-type = 'server'";
                            description
                              "A choice about how addresses are assigned
                               when a local DHCP server is enabled.";
                            choice address-assign {
                              default "number";
                              description
                                "Choice for how IPv4 addresses are
                                 assigned.";
                              case number {
                                leaf svlan-id number-of-dynamic-address {
                                  type uint16;
                        mandatory true;
                                  default "1";
                                  description
                          "Service VLAN ID.";
                                    "Specifies the number of IP
                                     addresses to be assigned to the
                                     customer on this access.";
                                }
                              }
                              case explicit {
                                container vxlan customer-addresses {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:vxlan')"
                                  description
                                    "Container for customer
                                     addresses to be allocated
                                     using DHCP.";
                                  list address-pool {
                                    key "pool-id";
                                    description
                          "Only applies when the type of the
                           tagged interface
                                      "Describes IP addresses to be
                                       allocated by DHCP.

                                       When only start-address or only
                                       end-address is 'vxlan'.";
                      }
                      if-feature "vpn-common:vxlan";
                      description
                        "QinQ."; present, it
                                       represents a single address.

                                       When both start-address and
                                       end-address are specified, it
                                       implies a range inclusive of both
                                       addresses.";
                                    leaf vni-id pool-id {
                                      type uint32;
                        mandatory true; string;
                                      description
                          "VXLAN Network Identifier (VNI).";
                                        "A pool identifier for the
                                         address range from start-
                                         address to end-address.";
                                    }
                                    leaf peer-mode start-address {
                                      type identityref {
                          base vpn-common:vxlan-peer-mode;
                        }
                        default "vpn-common:static-mode"; inet:ipv4-address;
                                      description
                          "Specifies
                                        "Indicates the VXLAN access mode. By default, first address
                                         in the peer mode is set to 'static-mode'."; pool.";
                                    }
                      list peer-list {
                        key "peer-ip";
                        description
                          "List of peer IP addresses.";
                                    leaf peer-ip end-address {
                                      type inet:ip-address; inet:ipv4-address;
                                      description
                            "Peer IP address.";
                                        "Indicates the last address
                                         in the pool.";
                                    }
                                  }
                                }
                              }
                  container bearer
                            }
                          }
                        }
                      }
                      case dhcp-relay {
                        when "derived-from-or-self(./address-allocation"
                           + "-type, 'provider-dhcp-relay')" {
                          description
                      "Defines physical properties of
                            "Only applies when the provider is required
                             to implement a site
                       attachment.";
                    leaf bearer-reference {
                      if-feature "vpn-common:bearer-reference";
                      type string; DHCP relay function that
                             will relay DHCP requests to a customer's
                             DHCP server.";
                        }
                        description
                        "This
                          "DHCP relay is an internal reference for provided by the service
                         provider.";
                    } operator.";
                        container pseudowire customer-dhcp-servers {
                          description
                        "Pseudowire termination parameters";
                      leaf vcid
                            "Container for a list of customer's DHCP
                             servers.";
                          leaf-list server-ip-address {
                            type uint32; inet:ipv4-address;
                            description
                          "Indicates a PW or VC identifier.";
                              "IPv4 addresses of the customer's DHCP
                               server.";
                          }
                      leaf far-end
                        }
                      }
                      case static-addresses {
                        type union
                        when "derived-from-or-self(./address-allocation"
                           + "-type, 'static-address')" {
                          type uint32;
                          type inet:ip-address;
                        }
                          description
                          "SDP/Far End/LDP neighbour reference.";
                      }
                            "Only applies when address allocation
                             type is static.";
                        }
                    container vpls {
                        description
                        "Pseudowire termination parameters";
                          "Lists the IPv4 addresses that are used.";
                        leaf vcid primary-address {
                          type union leafref {
                          type uint32;
                          type string;
                            path "../address/address-id";
                          }
                          description
                          "VCID identifier, IRB/RVPPLs interface
                           supported using string format.";
                            "Primary address of the connection.";
                        }
                      leaf far-end
                        list address {
                        type union
                          key "address-id";
                          description
                            "Lists the IPv4 addresses that are used.";
                          leaf address-id {
                            type uint32;
                          type inet:ip-address;
                        } string;
                            description
                          "SDP/Far End/LDP Neighbour reference.";
                      }
                    }
                  }
                              "An identifier of the static IPv4
                               address.";
                          }
                container ip-connection
                          leaf customer-address {
                            type inet:ipv4-address;
                            description
                    "Defines connection parameters.";
                              "IPv4 address at the customer side.";
                          }
                        }
                      }
                    }
                  }
                  container ipv4 ipv6 {
                    if-feature "vpn-common:ipv4"; "vpn-common:ipv6";
                    description
                      "IPv4-specific
                      "IPv6-specific parameters.";
                    leaf local-address {
                      type inet:ipv4-prefix; inet:ipv6-address;
                      description
                        "This
                        "IPv6 address is used at of the provider side.";

                    }
                    leaf prefix-length {
                      type uint8 {
                        range "0..128";
                      }
                      description
                        "Subnet prefix length expressed in bits.
                         It is applied to both local and customer
                         addresses.";
                    }
                    leaf address-allocation-type {
                      type identityref {
                        base address-allocation-type;
                      }
                      must "not(derived-from-or-self(current(), "
                         + "'slaac') or derived-from-or-self(current(),"
                         + " 'provider-dhcp-slaac'))" {
                        error-message
                          "SLAAC is only applicable to IPv6.";
                      }
                      description
                        "Defines how addresses are allocated to the
                         peer site. allocated.
                         If there is no value for the address
                         allocation type, then IPv4 IPv6 addressing is not enabled.";
                         disabled.";
                    }
                    choice allocation-type {
                      description
                        "Choice of
                        "A choice based on the IPv4 address allocation.";
                      case IPv6 allocation type.";
                      container provider-dhcp {
                        when "derived-from-or-self(./address-" "derived-from-or-self(../address-allo"
                           + "allocation-type, 'provider-dhcp')" "cation-type, 'provider-dhcp') "
                           + "or derived-from-or-self(../address-allo"
                           + "cation-type, 'provider-dhcp-slaac')" {
                          description
                            "Only applies when addresses are
                             allocated by DHCP."; DHCPv6 provided by the
                             operator.";
                        }
                        description
                          "DHCP
                          "DHCPv6 allocated addresses related
                           parameters.";
                        leaf dhcp-server-enable dhcp-service-type {
                          type boolean;
                          default "true"; enumeration {
                            enum server {
                              description
                            "Enables a DHCP
                                "Local DHCPv6 server.";
                            }
                            enum relay {
                              description
                                "DHCPv6 relay.";
                            }
                          }
                          description
                            "Indicates the type of the DHCPv6 service to
                             be enabled on this access.
                             The following information are passed to access.";
                        }
                        choice service-type {
                          description
                            "Choice based on the provider's DHCPv6 service type.";
                          case provider-dhcp-servers {
                            when "./dhcp-service-type = 'relay'";
                            description
                              "Case where a local DHCPv6 relay is
                               enabled. This list is used if and only
                               if a DHCP relay is enabled.";
                            leaf-list server-ip-address {
                              type inet:ipv6-address;
                              description
                                "IPv6 addresses of the provider's
                                 DHCPv6 server.";
                            }
                          }
                          case server {
                            when "./dhcp-service-type = 'server'";
                            description
                              "Case where a local DHCPv6 server is
                               enabled.";
                            choice address-assign {
                              default "number";
                              description
                                "Choice for about how IPv4 addresses IPv6 prefixes are
                             assigned.";
                                 assigned by the DHCPv6 server.";
                              case number {
                                leaf number-of-dynamic-address {
                                  type uint16;
                                  default "1";
                                  description
                                "Specifies
                                    "Describes the number of IP addresses
                                 to be assigned IPv6
                                     prefixes that are allocated to
                                     the customer on this access.";
                                }
                              }
                              case explicit {
                                container customer-addresses {
                                  description
                                    "Container for customer IPv6
                                     addresses to be allocated using DHCP."; by DHCPv6.";
                                  list address-group address-pool {
                                    key "group-id"; "pool-id";
                                    description
                                      "Describes IP IPv6 addresses to be
                                       allocated by DHCP. DHCPv6.

                                       When only start-address or only
                                       end-address is present, it
                                       represents a single address.

                                       When both start-address and
                                       end-address are specified, it
                                   implies a range inclusive of
                                   both addresses.  If no address
                                   is specified, it implies customer
                                   addresses group is not supported."; it
                                       implies a range inclusive of
                                       both addresses.";
                                    leaf group-id pool-id {
                                      type string;
                                      description
                                    "Group-id
                                        "Pool identifier for the address
                                         range from
                                     start-address to identified by start-
                                         address and end-address.";
                                    }
                                    leaf start-address {
                                      type inet:ipv4-address; inet:ipv6-address;
                                      description
                                        "Indicates the first address in
                                     the group."; address.";
                                    }
                                    leaf end-address {
                                      type inet:ipv4-address; inet:ipv6-address;
                                      description
                                        "Indicates the last address in the
                                     group."; address.";
                                    }
                                  }
                                }
                              }
                            }
                          }
                        }
                      }
                      case dhcp-relay {
                        when "derived-from-or-self(./address-allocation" "derived-from-or-self(./address-allo"
                           + "-type, "cation-type, 'provider-dhcp-relay')" {
                          description
                            "Only applies when the provider is required
                             to implement DHCP relay function."; function that will
                             relay DHCPv6 requests to a customer's DHCP
                             server.";
                        }
                        description
                          "DHCP
                          "DHCPv6 relay provided by operator.";
                        leaf dhcp-relay-enable {
                          type boolean;
                          default "true";
                          description
                            "Enables the DHCP relay function for this
                             access.";
                        } operator.";
                        container customer-dhcp-servers {
                          description
                            "Container for a list of customer DHCP
                             servers.";
                          leaf-list server-ip-address {
                            type inet:ipv4-address; inet:ipv6-address;
                            description
                              "IP address
                              "Contains the IP addresses of the customer DHCP
                               DHCPv6 server.";
                          }
                        }
                      }
                      case static-addresses {
                        when "derived-from-or-self(./address-allocation"
                           + "-type, 'static-address')" {
                          description
                            "Only applies when address protocol allocation type
                             is static.";
                        }
                        description
                          "Describes IPv4 addresses used.";
                          "IPv6-specific parameters for static
                           allocation.";
                        leaf primary-address {
                          type leafref {
                            path "../address/address-id";
                          }
                          description
                            "Primary
                            "Principal address of the connection."; connection";
                        }
                        list address {
                          key "address-id";
                          description
                            "Describes IPv4 IPv6 addresses that are used.";
                          leaf address-id {
                            type string;
                            description
                              "Used static IPv4 address.";
                          }
                          leaf customer-address {
                            type inet:ipv4-address;
                            description
                              "IPv4 address at the customer side.";
                          }
                        }
                      }
                    }
                  }
                  container ipv6 {
                    if-feature "vpn-common:ipv6";
                    description
                      "IPv6-specific parameters.";
                    leaf local-address {
                      type inet:ipv6-prefix;
                      description
                        "Address
                              "An identifier of the provider side.";
                    }
                    leaf address-allocation-type {
                      type identityref {
                        base address-allocation-type;
                      }
                      description
                        "Defines how addresses are allocated.
                         If there is no value for the address
                         allocation type, then an IPv6 is
                         not enabled.";
                    }
                    choice allocation-type {
                      description
                        "IPv6 allocation type.";
                      case provider-dhcp {
                        when "derived-from-or-self(./address-allo"
                           + "cation-type, 'provider-dhcp') "
                           + "or derived-from-or-self(./address-allo"
                           + "cation-type, 'provider-dhcp-slaac')" {
                          description
                            "Only applies when addresses are
                             allocated by DHCPv6."; address.";
                          }
                        description
                          "DHCPv6 allocated addresses related
                           parameters.";
                          leaf dhcp-server-enable customer-address {
                            type boolean;
                          default "true";
                          description
                            "Enables DHCPv6 service for this access.";
                        }
                        choice address-assign {
                          default "number"; inet:ipv6-address;
                            description
                            "Choice for the way to assign
                              "An IPv6
                             prefixes.";
                          case number {
                            leaf number-of-dynamic-address {
                              type uint16;
                              default "1";
                              description
                                "Describes the number address of IPv6 prefixes
                                 that are allocated to the customer
                                 on this access."; side.";
                          }
                        }
                      }
                    }
                  }
                }
                          case explicit {
                container customer-addresses routing-protocols {
                  description
                                "Container for customer IPv6 addresses
                                 allocated by DHCPv6.";
                    "Defines routing protocols.";

                  list address-group routing-protocol {
                    key "group-id"; "id";
                    description
                                  "Describes IPv6 addresses allocated
                                   by DHCPv6.

                                   When only start-address or only
                                   end-address is present, it
                                   represents a single address.

                                   When both start-address and
                                   end-address are specified, it
                                   implies a range inclusive
                      "List of
                                   both addresses.

                                   If no address is specified, it
                                   implies customer addresses group
                                   is not supported."; routing protocols used on
                       the CE/PE link.  This list can be augmented.";
                    leaf group-id id {
                      type string;
                      description
                                    "Group-id
                        "Unique identifier for the address range
                                     from identified by start-address
                                     and end-address."; routing protocol.";
                    }
                    leaf start-address type {
                      type inet:ipv6-address; identityref {
                        base vpn-common:routing-protocol-type;
                      }
                      description
                                    "Indicates the first address.";
                        "Type of routing protocol.";
                    }
                    list routing-profiles {
                      key "id";
                      description
                        "Routing profiles.";
                      leaf end-address id {
                        type inet:ipv6-address;
                                  description
                                    "Indicates the last address.";
                                } leafref {
                          path "/l3vpn-ntw/vpn-profiles"
                             + "/valid-provider-identifiers"
                             + "/routing-profile-identifier/id";
                        }
                        description
                          "Routing profile to be used.";
                      }
                      leaf type {
                        type identityref {
                          base vpn-common:ie-type;
                        }
                        description
                          "Import, export or both.";
                      }
                    }
                      case dhcp-relay
                    container static {
                      when "derived-from-or-self(./address-allo" "derived-from-or-self(../type, "
                         + "cation-type, 'provider-dhcp-relay')" "'vpn-common:static')" {
                        description
                          "Only applies when protocol is static.";
                      }
                      description
                        "Configuration specific to static routing.";
                      container cascaded-lan-prefixes {
                        description
                          "LAN prefixes from the provider customer.";
                        list ipv4-lan-prefixes {
                          if-feature "vpn-common:ipv4";
                          key "lan next-hop";
                          description
                            "List of LAN prefixes for the site.";
                          leaf lan {
                            type inet:ipv4-prefix;
                            description
                              "LAN prefixes.";
                          }
                          leaf lan-tag {
                            type string;
                            description
                              "Internal tag to be used in VPN
                               policies.";
                          }
                          leaf next-hop {
                            type union {
                              type inet:ip-address;
                              type predefined-next-hop;
                            }
                            description
                              "The next-hop that is required to implement DHCP relay function."; be used
                               for the static route. This may be
                               specified as an IP address, an interface,
                               or a pre-defined next-hop type (e.g.,
                               discard or local-link).";
                          }
                        description
                          "DHCP relay provided by operator.";
                          leaf dhcp-relay-enable bfd-enable {
                            if-feature "vpn-common:bfd";
                            type boolean;
                          default "true";
                            description
                              "Enables the DHCP relay function for this
                             access."; BFD.";
                          }
                        container customer-dhcp-servers
                          leaf metric {
                            type uint32;
                            description
                            "Container for list of customer DHCP
                             servers.";
                          leaf-list server-ip-address
                              "Indicates the metric associated with
                               the static route.";
                          }
                          leaf preference {
                            type inet:ipv6-address; uint32;
                            description
                              "This node contains
                              "Indicates the IP address preference of the customer DHCP server.  If the DHCP
                               relay function is implemented by the
                               provider, this node contains the
                               configured value.";
                          } static
                               routes.";
                          }
                          uses vpn-common:service-status;

                        }
                      case static-addresses {
                        when "derived-from-or-self(./address-allocation"
                           + "-type, 'static-address')"
                        list ipv6-lan-prefixes {
                          if-feature "vpn-common:ipv6";
                          key "lan next-hop";
                          description
                            "Only applies when protocol allocation
                            "List of LAN prefixes for the site.";
                          leaf lan {
                            type
                             is static."; inet:ipv6-prefix;
                            description
                              "LAN prefixes.";
                          }
                          leaf lan-tag {
                            type string;
                            description
                          "IPv6-specific parameters for static
                           allocation.";
                              "Internal tag to be used in VPN
                               policies.";
                          }
                          leaf primary-address next-hop {
                            type leafref union {
                            path "../address/prefix-id";
                              type inet:ip-address;
                              type predefined-next-hop;
                            }
                            description
                            "Principal address of
                              "The next-hop that is to be used for the connection";
                               static route. This may be specified as
                               an IP address, an interface, or a
                               pre-defined next-hop type (e.g.,
                               discard or local-link).";
                          }
                        list address
                          leaf bfd-enable {
                          key "prefix-id";
                            if-feature "vpn-common:bfd";
                            type boolean;
                            description
                            "Describes IPv6 prefixes used.";
                              "Enables BFD.";
                          }
                          leaf prefix-id metric {
                            type string; uint32;
                            description
                              "An identifier of an IPv6 prefix.";
                              "Indicates the metric associated with
                               the static route.";
                          }
                          leaf customer-prefix preference {
                            type inet:ipv6-prefix; uint32;
                            description
                              "An IPv6 prefix of
                              "Indicates the customer side.";
                          }
                        } preference associated
                               with the static route.";
                          }
                          uses vpn-common:service-status;

                        }
                      }
                    }
                    container routing-protocols bgp {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:bgp')" {
                        description
                    "Defines routing protocols.";
                  list routing-protocol
                          "Only applies when protocol is BGP.";
                      }
                      if-feature "vpn-common:rtg-bgp";
                      description
                        "BGP-specific configuration.";
                      leaf description {
                    key "id";
                        type string;
                        description
                          "Includes a description
                      "List of routing protocols used on the CE/PE link.  This list can BGP session.

                           Such description is meant to be augmented."; used for
                           diagnosis purposes. The semantic of the
                           description is local to an
                           implementation.";
                      }
                      leaf id local-autonomous-system {
                        type string; inet:as-number;
                        description
                        "Unique identifier for routing protocol.";
                          "Indicates a local AS Number (ASN) if a
                           distinct ASN than the one configured at
                           the VPN node level is needed.";
                      }
                      leaf type peer-autonomous-system {
                        type identityref {
                        base vpn-common:routing-protocol-type;
                      } inet:as-number;
                        mandatory true;
                        description
                        "Type of routing protocol.";
                          "Indicates the customer's ASN in
                           case the customer requests BGP routing.";
                      }
                    list routing-profiles {
                      key "id";
                      description
                        "Routing profiles.";
                      leaf id address-family {
                        type leafref identityref {
                          path "/l3vpn-ntw/vpn-profiles"
                             + "/valid-provider-identifiers"
                             + "/routing-profile-identifier/id";
                          base vpn-common:address-family;
                        }
                        description
                          "Routing profile
                          "This node contains the address families to be used.";
                           activated. Dual-stack means that both IPv4
                           and IPv6 will be activated.";
                      }
                      leaf type local-address {
                        type identityref union {
                          base vpn-common:ie-type;
                          type inet:ip-address;
                          type if:interface-ref;
                        }
                        description
                          "Import, export
                          "Set the local IP address to use for the BGP
                           transport session. This may be expressed as
                           either an IP address or both.";
                      } a reference to an
                           interface.";
                      }
                    container static {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:static')"
                      leaf-list neighbor {
                        type inet:ip-address;
                        description
                          "Only applies when protocol is static.";
                          "IP address(es) of the BGP neighbor. IPv4
                           and IPv6 neighbors may be indicated if
                           two sessions will be used for IPv4 and
                           IPv6.";
                      }
                      description
                        "Configuration specific to static routing.";
                      container cascaded-lan-prefixes
                      leaf multihop {
                        type uint8;
                        description
                          "LAN prefixes from
                          "Describes the customer.";
                        list ipv4-lan-prefixes {
                          if-feature "vpn-common:ipv4";
                          key "lan next-hop";
                          description
                            "List number of LAN prefixes for IP hops allowed
                           between a given BGP neighbor and the site."; PE.";
                      }
                      leaf lan as-override {
                        type inet:ipv4-prefix; boolean;
                        default "false";
                        description
                              "LAN prefixes.";
                          "Defines whether ASN override is enabled,
                           i.e., replace the ASN of the customer
                           specified in the AS_Path attribute with
                           the local ASN.";
                      }
                      leaf lan-tag allow-own-as {
                        type string; uint8;
                        default "0";
                        description
                              "Internal tag to be used in VPN
                               policies.";
                          "Specifies the number of occurrences
                           of the provider's ASN that can occur
                           within the AS_PATH before it
                           is rejected.";
                      }
                      leaf next-hop {
                            type union prepend-global-as {
                        type inet:ip-address;
                              type predefined-next-hop;
                            } boolean;
                        default "false";
                        description
                              "The next-hop
                          "In some situations, the ASN that is to be used
                               for
                           provided at the static route. This VPN node level may be
                               specified as an IP address, an interface,
                               or a pre-defined next-hop type (e.g.,
                               discard or local-link).";
                           distinct from the one configured at the
                           VPN network access level. When set to
                           'true', this parameter prevents that
                           the ASN provided at the VPN node
                           level is also prepended to the BGP
                           route updates for this access.";
                      }
                      leaf bfd-enable default-route {
                            if-feature "vpn-common:bfd";
                        type boolean;
                        default "false";
                        description
                              "Enables BFD.";
                          "Defines whether default routes can be
                           advertised to its peer. If set, the
                           default routes are advertised to its
                           peer.";
                      }
                      leaf metric site-of-origin {
                        when "../address-family = 'vpn-common:ipv4' or "
                           + "'vpn-common:dual-stack'" {
                          description
                            "Only applies if IPv4 is activated.";
                        }
                        type uint32; rt-types:route-origin;
                        description
                              "Indicates the metric associated with
                          "The Site of Origin attribute is encoded as
                           a Route Origin Extended Community. It is
                           meant to uniquely identify the static route."; set of routes
                           learned from a site via a particular CE/PE
                           connection and is used to prevent routing
                           loops.";
                        reference
                          "RFC 4364: BGP/MPLS IP Virtual Private
                                     Networks (VPNs), Section 7";
                      }
                      leaf preference ipv6-site-of-origin {
                        when "../address-family = 'vpn-common:ipv6' or "
                           + "'vpn-common:dual-stack'" {
                          description
                            "Only applies if IPv6 is activated.";
                        }
                        type uint32; rt-types:ipv6-route-origin;
                        description
                              "Indicates
                          "IPv6 Route Origins are IPv6 Address Specific
                           BGP Extended that are meant to the preference Site of the static
                               routes.";
                          }
                          uses vpn-common:service-status;
                           Origin for VRF information.";
                        reference
                          "RFC 5701: IPv6 Address Specific BGP Extended
                                     Community Attribute";
                      }
                      list ipv6-lan-prefixes redistribute-connected {
                          if-feature "vpn-common:ipv6";
                        key "lan next-hop"; "address-family";
                        description
                            "List of LAN prefixes for
                          "Indicates the site.";
                          leaf lan {
                            type inet:ipv6-prefix;
                            description
                              "LAN prefixes.";
                          }
                          leaf lan-tag {
                            type string;
                            description
                              "Internal tag per-AF policy to be used in VPN
                               policies.";
                          } follow
                           for connected routes.";
                        leaf next-hop address-family {
                          type union identityref {
                              type inet:ip-address;
                              type predefined-next-hop;
                            base vpn-common:address-family;
                          }
                          description
                              "The next-hop that is to be used for
                            "Indicates the
                               static route. This may be specified as
                               an IP address, an interface, or a
                               pre-defined next-hop type (e.g.,
                               discard or local-link)."; address family.";
                        }
                        leaf bfd-enable enable {
                            if-feature "vpn-common:bfd";
                          type boolean;
                          description
                            "Enables BFD."; to redistribute connected
                             routes.";
                        }
                          leaf metric
                      }
                      container bgp-max-prefix {
                            type uint32;
                        description
                              "Indicates the metric associated with
                          "Controls the static route.";
                          } behavior when a prefix
                           maximum is reached.";
                        leaf preference max-prefix {
                          type uint32;
                          default "5000";
                          description
                            "Indicates the preference associated
                               with maximum number of BGP
                             prefixes allowed in the static route.";
                          }
                          uses vpn-common:service-status;
                        }
                      } BGP session.

                             It allows to control how many prefixes
                             can be received from a neighbor.

                             If the limit is exceeded, the action
                             indicated in violate-action will be
                             followed.";
                          reference
                            "RFC 4271: A Border Gateway Protocol 4
                                       (BGP-4), Section 8.2.2";
                        }
                    container bgp
                        leaf warning-threshold {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:bgp')"
                          type decimal64 {
                            fraction-digits 5;
                            range "0..100";
                          }
                          units "percent";
                          default "75";
                          description
                          "Only applies when protocol
                            "When this value is BGP."; reached, a warning
                             notification will be triggered.";
                        }
                      if-feature "vpn-common:rtg-bgp";
                      description
                        "BGP-specific configuration.";
                        leaf description violate-action {
                          type string; enumeration {
                            enum warning {
                              description
                          "Includes
                                "Only a description of the BGP session.

                           Such description warning message is meant sent to be used for
                           diagnosis purposes. The semantic of
                                 the
                           description peer when the limit is local to an
                           implementation.";
                                 exceeded.";
                            }
                      leaf local-autonomous-system
                            enum discard-extra-paths {
                        type inet:as-number;
                              description
                          "Is set to
                                "Discards extra paths when the ASN to override a peers' ASN
                           if such feature
                                 limit is requested by the
                           Customer."; exceeded.";
                            }
                      leaf peer-autonomous-system
                            enum restart {
                        type inet:as-number;
                        mandatory true;
                              description
                          "Indicates the Customer's AS Number (ASN) in
                           case the Customer requests BGP routing.";
                                "Restarts after a time interval.";
                            }
                          }
                          description
                            "BGP neighbour max-prefix violate
                             action";
                        }
                        leaf address-family restart-interval {
                          type identityref {
                          base vpn-common:address-family;
                        } uint16;
                          units "minutes";
                          description
                          "This node contains
                            "Time interval (min) after which the address families to be
                           activated. Dual-stack means that both IPv4
                           and IPv6
                             BGP session will be activated."; reestablished.";
                        }
                      leaf-list neighbor
                      }
                      container bgp-timers {
                        type inet:ip-address;
                        description
                          "IP address(es) of the BGP neighbor. IPv4
                           and IPv6 neighbors may be indicated if
                          "Includes two sessions will BGP timers that can be
                           customized when building a VPN service
                           with BGP used for IPv4 and
                           IPv6.";
                      } as CE-PE routing
                           protocol.";
                        leaf multihop keep-alive {
                          type uint8; uint16 {
                            range "0..21845";
                          }
                          units "seconds";
                          default "30";
                          description
                          "Describes
                            "This timer indicates the number of IP hops allowed KEEPALIVE
                             messages'  frequency between a given BGP neighbor PE
                             and a BGP peer.

                             If set to '0', it indicates KEEPALIVE
                             messages are disabled.

                             It is suggested that the PE."; maximum time
                             between  KEEPALIVEmessages would be
                             one third of the Hold Time interval.";
                          reference
                            "RFC 4271: A Border Gateway Protocol 4
                                       (BGP-4), Section 4.4";
                        }
                        leaf as-override hold-time {
                          type boolean; uint16 {
                            range "0 | 3..65535";
                          }
                          units "seconds";
                          default "false"; "90";
                          description
                          "Defines whether AS override is enabled,
                           i.e., replace
                            "It indicates the ASN maximum number of
                             seconds that may elapse between the customer
                           specified in the AS Path attribute with
                             receipt of successive KEEPALIVE
                             and/or UPDATE   messages from the local ASN."; peer.

                             The Hold Time must be either zero or
                             at least three seconds.";
                          reference
                            "RFC 4271: A Border Gateway Protocol 4
                                       (BGP-4), Section 4.2";
                        }
                      }
                      container security {
                        description
                          "Container for BGP security parameters
                           between a PE and a CE.";
                        leaf default-route enable {
                          type boolean;
                          default "false";
                          description
                          "Defines whether default route(s) can be
                           advertised to its peer. If set, the
                           default route(s) is advertised to its
                           peer.";
                            "Enables or disables authentication.";
                        }
                      leaf site-of-origin
                        container keying-material {
                          when "../address-family "../enable = 'vpn-common:ipv4' or "
                           + "'vpn-common:dual-stack'" {

                          description
                            "Only applies if IPv4 is activated.";
                        }
                        type rt-types:route-origin; 'true'";
                          description
                          "The Site of Origin attribute is encoded as
                            "Container for describing how a Route Origin Extended Community. It BGP routing
                             session is
                           meant to uniquely identify the set of routes
                           learned from a site via be secured between a particular CE/PE
                           connection PE and is used to prevent routing
                           loops.";
                             a CE.";
                          choice option {
                            description
                              "Choice of authentication options.";

                            case tcp-ao {
                              description
                                "Uses TCP-Authentication Option
                                 (TCP-AO).";
                              reference
                          "RFC4364, Section 7";
                      }
                                "RFC 5925: The TCP Authentication
                                           Option.";
                              leaf ipv6-site-of-origin {
                        when "../address-family = 'vpn-common:ipv6' or "
                           + "'vpn-common:dual-stack'" enable-tcp-ao {
                                type boolean;
                                description
                            "Only applies if IPv6 is activated.";
                                  "Enables TCP-AO.";
                              }
                              leaf ao-keychain {
                                type rt-types:ipv6-route-origin; key-chain:key-chain-ref;
                                description
                          "IPv6 Route Origins are IPv6 Address Specific
                           BGP Extended that are meant
                                  "Reference to the Site of
                           Origin for VRF information."; TCP-AO key chain.";
                                reference
                                  "RFC 5701: IPv6 Address Specific BGP Extended
                                     Community Attribute"; 8177: YANG Key Chain.";
                              }
                      container bgp-max-prefix
                            }
                            case md5 {
                              description
                          "Controls
                                "Uses MD5 to secure the behavior when a prefix
                           maximum is reached."; session.";
                              reference
                                "RFC 4364: BGP/MPLS IP Virtual Private
                                           Networks (VPNs),
                                           Section 13.2";
                              leaf max-prefix md5-keychain {
                                type uint32;
                          default "5000"; key-chain:key-chain-ref;
                                description
                            "Indicates the maximum number of BGP
                             prefixes allowed in the BGP session.

                             It allows
                                  "Reference to control how many prefixes
                             can be received from a neighbor.

                             If the limit is exceeded, the action
                             indicated in violate-action will be
                             followed."; MD5 key chain.";
                                reference
                            "RFC4271, Section 8.2.2.";
                                  "RFC 8177: YANG Key Chain.";
                              }
                            }
                            case explicit {
                              leaf warning-threshold key-id {
                                type decimal64 {
                            fraction-digits 5;
                            range "0..100"; uint32;
                                description
                                  "Key Identifier";
                              }
                          units "percent";
                          default "75";
                              leaf key {
                                type string;
                                description
                            "When this value is reached, a warning
                             notification will be triggered.";
                                  "BGP authentication key.";
                              }
                              leaf violate-action crypto-algorithm {
                                type enumeration identityref {
                            enum warning
                                  base key-chain:crypto-algorithm;
                                }
                                description
                                  "Indicates the cryptographic algorithm
                                   associated with the key.";
                              }
                            }
                            case ipsec {
                              description
                                "Only
                                "Specifies a warning message is sent reference to an IKE
                                 Security Association (SA).";
                              leaf sa {
                                type string;
                                description
                                  "Indicates the peer when name of the limit is
                                 exceeded."; SA.";
                              }
                            enum discard-extra-paths
                            }
                          }
                        }
                      }
                      uses vpn-common:service-status;
                    }
                    container ospf {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:ospf')" {
                        description
                                "Discards extra paths
                          "Only applies when the
                                 limit protocol is exceeded."; OSPF.";
                      }
                            enum restart {
                      if-feature "vpn-common:rtg-ospf";
                      description
                                "Restarts after a time interval.";
                        "OSPF-specific configuration.";
                      leaf address-family {
                        type identityref {
                          base vpn-common:address-family;
                        }
                        description
                          "Indicates whether IPv4, IPv6, or
                           both are to be activated.";
                      }
                      leaf area-id {
                        type yang:dotted-quad;
                        mandatory true;
                        description
                            "BGP neighbour max-prefix violate
                             action";
                          "Area ID.";
                        reference
                          "RFC 4577: OSPF as the Provider/Customer
                                     Edge Protocol for BGP/MPLS IP
                                     Virtual Private Networks
                                     (VPNs), Section 4.2.3
                           RFC 6565: OSPFv3 as a Provider Edge to
                                     Customer Edge (PE-CE) Routing
                                     Protocol, Section 4.2";
                      }
                      leaf restart-interval metric {
                        type uint16;
                          units "minutes";
                        default "1";
                        description
                            "Time interval (min) after which
                          "Metric of the
                             BGP session will be reestablished.";
                        } PE-CE link. It is used
                           in the routing state calculation and
                           path selection.";
                      }
                      container bgp-timers sham-links {
                        if-feature "vpn-common:rtg-ospf-sham-link";
                        description
                          "Includes two BGP timers that can be
                           customized when building
                          "List of sham links.";
                        reference
                          "RFC 4577: OSPF as the Provider/Customer
                                     Edge Protocol for BGP/MPLS IP
                                     Virtual Private Networks
                                     (VPNs), Section 4.2.7
                           RFC 6565: OSPFv3 as a VPN service Provider Edge to
                                     Customer Edge (PE-CE) Routing
                                     Protocol, Section 5";
                        list sham-link {
                          key "target-site";
                          description
                            "Creates a sham link with BGP used as CE-PE routing
                           protocol."; another site.";
                          leaf keep-alive target-site {
                            type uint16 {
                            range "0..21845";
                          }
                          units "seconds";
                          default "30"; vpn-common:vpn-id;
                            description
                            "This timer indicates
                              "Target site for the KEEPALIVE
                             messages'  frequency between a PE
                             and a BGP peer.

                             If set to '0', it indicates KEEPALIVE
                             messages are disabled.

                             It sham link connection.
                               The site is suggested that the maximum time
                             between  KEEPALIVEmessages would be
                             one third of the Hold Time interval.";
                          reference
                            "Section 4.4 of RFC 4271"; referred to by its ID.";
                          }
                          leaf hold-time metric {
                            type uint16 {
                            range "0 | 3..65535";
                          }
                          units "seconds"; uint16;
                            default "90"; "1";
                            description
                            "It indicates the maximum number
                              "Metric of
                             seconds that may elapse between the
                             receipt of successive KEEPALIVE
                             and/or UPDATE   messages from sham link.  It is used in
                               the peer. routing state calculation and path
                               selection.  The Hold Time must be either zero or
                             at least three seconds."; default value is set
                               to 1.";
                            reference
                            "Section 4.2 of
                              "RFC 4577: OSPF as the Provider/Customer
                                         Edge Protocol for BGP/MPLS IP
                                         Virtual Private Networks
                                         (VPNs), Section 4.2.7.3

                               RFC 4271"; 6565: OSPFv3 as a Provider Edge to
                                         Customer Edge (PE-CE) Routing
                                         Protocol, Section 5.2";
                          }
                        }
                      }
                      leaf max-lsa {
                        type uint32 {
                          range "1..4294967294";
                        }
                        description
                          "Maximum number of allowed LSAs OSPF.";
                      }
                      container security {
                        description
                          "Container for BGP security parameters
                           between a PE and a CE.";
                          "Authentication configuration.";
                        leaf enable {
                          type boolean;
                          default "false";
                          description
                            "Enables or disables authentication.";
                        }
                        container keying-material {
                          when "../enable = 'true'";
                          description
                            "Container for describing how a BGP routing an OSPF
                             session is to be secured between a PE CE
                             and a CE."; PE.";
                          choice option {
                            description
                              "Choice of authentication options.";
                            case tcp-ao {
                              description
                                "Uses TCP-Authentication Option
                                 (TCP-AO).";
                              reference
                                "RFC 5925: The TCP Authentication
                                           Option.";
                              leaf enable-tcp-ao {
                                type boolean;
                                description
                                  "Enables TCP-AO.";
                              }
                              leaf ao-keychain {
                                type key-chain:key-chain-ref;
                                description
                                  "Reference to the TCP-AO key chain.";
                                reference
                                  "RFC 8177: YANG Key Chain.";
                              }
                            }
                              "Options for OSPF authentication.";
                            case md5 auth-key-chain {
                              description
                                "Uses MD5 to secure the session.";
                              reference
                                "Section 13.2 of RFC 4364";
                              leaf md5-keychain key-chain {
                                type key-chain:key-chain-ref;
                                description
                                  "Reference to the MD5 key chain.";
                                reference
                                  "RFC 8177: YANG Key Chain.";
                                  "key-chain name.";
                              }
                            }
                            case explicit auth-key-explicit {
                              leaf key-id {
                                type uint32;
                                description
                                  "Key Identifier"; identifier.";
                              }
                              leaf key {
                                type string;
                                description
                                  "OSPF authentication key.";

                              }
                              leaf crypto-algorithm {
                                type identityref {
                                  base key-chain:crypto-algorithm;
                                }
                                description
                                  "Indicates the cryptographic algorithm
                                   associated with the key.";
                              }
                            }
                            case ipsec {
                              description
                                "Specifies a reference to an IKE
                                 Security Association (SA).";
                              leaf sa {
                                type string;
                                description
                                  "Indicates the name of the SA.";
                                reference
                                  "RFC 4552: Authentication
                                             /Confidentiality for
                                             OSPFv3";
                              }
                            }
                          }
                        }
                      }
                      uses vpn-common:service-status;
                    }
                    container ospf isis {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:ospf')" "'vpn-common:isis')" {
                        description
                          "Only applies when protocol is OSPF."; IS-IS.";
                      }
                      if-feature "vpn-common:rtg-ospf"; "vpn-common:rtg-isis";
                      description
                        "OSPF-specific
                        "IS-IS specific configuration.";
                      leaf address-family {
                        type identityref {
                          base vpn-common:address-family;
                        }
                        description
                          "Indicates whether IPv4, IPv6, or both
                           are to be activated.";
                      }
                      leaf area-id area-address {
                        type yang:dotted-quad; area-address;
                        mandatory true;
                        description
                          "Area ID."; address.";

                      }
                      leaf metric level {
                        type uint16;
                        default "1";
                        description
                          "Metric of the PE-CE link. It is used
                           in the routing state calculation and
                           path selection.";
                      }
                      container sham-links {
                        if-feature "vpn-common:rtg-ospf-sham-link";
                        description
                          "List of sham links.";
                        list sham-link {
                          key "target-site";
                          description
                            "Creates a sham link with another site.";
                          leaf target-site identityref {
                            type vpn-common:vpn-id;
                          base vpn-common:isis-level;
                        }
                        description
                              "Target site for the sham link connection.
                               The site is referred to by its ID.";
                          "Can be level1, level2, or level1-2.";
                      }
                      leaf metric {
                        type uint16;
                        default "1";
                        description
                          "Metric of the sham PE-CE link.  It is used in
                               the routing state calculation and path
                               selection.  The default value is set
                               to 1.";
                          }
                        }
                           in the routing state calculation and
                           path selection.";
                      }
                      leaf max-lsa mode {
                        type uint32 enumeration {
                          range "1..4294967294";
                          enum active {
                            description
                              "Interface sends or receives IS-IS
                               protocol control packets.";
                          }
                          enum passive {
                            description
                          "Maximum number
                              "Suppresses the sending of allowed LSAs OSPF."; IS-IS
                               updates through the specified
                               interface.";
                          }
                        }
                        default "active";
                        description
                          "IS-IS interface mode type.";
                      }
                      container security {
                        description
                          "Authentication configuration.";
                        leaf enable {
                          type boolean;
                          default "false";
                          description
                            "Enables or disables authentication.";
                        }
                        container keying-material {
                          when "../enable = 'true'";
                          description
                            "Container for describing how an OSPF IS-IS
                             session is to be secured between a CE
                             and a PE.";
                          choice option {
                            description
                              "Options for OSPF IS-IS authentication.";
                            case auth-key-chain {
                              leaf key-chain {
                                type key-chain:key-chain-ref;
                                description
                                  "key-chain name.";
                              }
                            }
                            case auth-key-explicit {
                              leaf key-id {
                                type uint32;
                                description
                                  "Key Identifier";
                              }
                              leaf key {
                                type string;
                                description
                                  "OSPF
                                  "IS-IS authentication key.";
                              }
                              leaf crypto-algorithm {
                                type identityref {
                                  base key-chain:crypto-algorithm;
                                }
                                description
                                  "Indicates the cryptographic algorithm
                                   associated with the key.";
                              }
                            }
                            case ipsec {
                              leaf sa {
                                type string;
                                description
                                  "Indicates the name of the SA.";
                              }
                            }
                          }
                        }
                      }
                      uses vpn-common:service-status;
                    }
                    container isis rip {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:isis')" "'vpn-common:rip')" {
                        description
                          "Only applies when the protocol is IS-IS."; RIP.
                           For IPv4, the model assumes that RIP
                           version 2 is used.";
                      }
                      if-feature "vpn-common:rtg-isis"; "vpn-common:rtg-rip";
                      description
                        "IS-IS
                        "Configuration specific configuration."; to RIP routing.";
                      leaf address-family {
                        type identityref {
                          base vpn-common:address-family;
                        }
                        description
                          "Indicates whether IPv4, IPv6, or both
                           address families are to be activated.";
                      }
                      leaf area-address
                      container timers {
                        type yang:dotted-quad;
                        mandatory true;
                        description
                          "Area address.";
                      }
                          "Indicates the RIP timers.";
                        reference
                          "RFC 2453: RIP Version 2";
                        leaf level update-interval {
                          type identityref uint16 {
                          base vpn-common:isis-level;
                            range "1..32767";
                          }
                          units "seconds";
                          default "30";
                          description
                          "Can be level1, level2, or level1-2.";
                            "Indicates the RIP update time.
                             That is, the amount of time for which
                             routing updates are sent.";
                        }
                        leaf metric invalid-interval {
                          type uint16; uint16 {
                            range "1..32767";
                          }
                          units "seconds";
                          default "1"; "180";
                          description
                          "Metric of
                            "Is the PE-CE link.  It interval before a route is used
                           in declared
                             invalid after no updates are received.
                             This value is at least three times
                             the routing state calculation and
                           path selection."; value for the update-interval
                             argument.";
                        }
                        leaf mode holddown-interval {
                          type enumeration {
                          enum active uint16 {
                            range "1..32767";
                          }
                          units "seconds";
                          default "180";
                          description
                              "Interface sends or receives IS-IS
                               protocol control packets.";
                            "Specifies the interval before better routes
                             are released.";
                        }
                          enum passive
                        leaf flush-interval {
                          type uint16 {
                            range "1..32767";
                          }
                          units "seconds";
                          default "180";
                          description
                              "Suppresses
                            "Indicates the sending RIP  flush timer. That is,
                             the amount of IS-IS
                               updates through time that must elapse before
                             a route is removed from the specified
                               interface."; routing
                             table.";
                        }
                      }
                      leaf default-metric {
                        type uint8 {
                          range "0..16";
                        }
                        default "active"; "1";
                        description
                          "IS-IS interface mode type.";
                          "Sets the default metric.";
                      }
                      container security {
                        description
                          "Authentication configuration.";
                        leaf enable {
                          type boolean;
                          default "false";
                          description
                            "Enables or disables authentication.";
                        }
                        container keying-material {
                          when "../enable = 'true'";
                          description
                            "Container for describing how an IS-IS a RIP
                             session is to be secured between a CE
                             and a PE.";
                          choice option {
                            description
                              "Options for IS-IS authentication.";
                              "Specifies the authentication scheme.";
                            case auth-key-chain {
                              leaf key-chain {
                                type key-chain:key-chain-ref;
                                description
                                  "key-chain name.";
                              }
                            }
                            case auth-key-explicit {
                              leaf key-id {
                                type uint32;
                                description
                                  "Key Identifier";
                              }
                              leaf key {
                                type string;
                                description
                                  "IS-IS
                                  "RIP authentication key.";
                              }
                              leaf crypto-algorithm {
                                type identityref {
                                  base key-chain:crypto-algorithm;
                                }
                                description
                                  "Indicates the cryptographic algorithm
                                   associated with the key.";
                              }
                            }
                          }
                        }
                      }
                      uses vpn-common:service-status;
                    }
                    container rip {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:rip')" {
                        description
                          "Only applies when the protocol is RIP.
                           For IPv4, the model assumes that RIP
                           version 2 is used.";
                      }
                      if-feature "vpn-common:rtg-rip";
                      description
                        "Configuration specific to RIP routing.";
                      leaf address-family {
                        type identityref {
                          base vpn-common:address-family;
                        }
                        description
                          "Indicates whether IPv4, IPv6, or both
                           address families are to be activated.";
                      }
                      uses vpn-common:service-status;
                    }
                    container vrrp {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:vrrp')" {
                        description
                          "Only applies when protocol is VRRP.";
                      }
                      if-feature "vpn-common:rtg-vrrp";
                      description
                        "Configuration specific to VRRP.";
                      reference
                        "RFC 5798: Virtual Router Redundancy Protocol
                                   (VRRP) Version 3 for IPv4 and IPv6";
                      leaf address-family {
                        type identityref {
                          base vpn-common:address-family;
                        }
                        description
                          "Indicates whether IPv4, IPv6, or both
                           address families are to be enabled.";
                      }
                      leaf vrrp-group {
                        type uint8 {
                          range "1..255";
                        }
                        description
                          "Includes the VRRP group identifier.";
                      }
                      leaf backup-peer {
                        type inet:ip-address;
                        description
                          "Indicates the IP address of the peer.";
                      }
                      leaf priority {
                        type uint8 {
                          range "1..254";
                        }
                        default "100";
                        description
                          "Sets the local priority of the VRRP
                           speaker.";
                      }
                      leaf ping-reply {
                        type boolean;
                        description
                          "Controls whether the VRRP speaker should
                           answer to ping requests.";
                      }
                      uses vpn-common:service-status;
                    }
                  }
                }
                container oam {
                  description
                    "Defines the Operations, Administration,
                     and Maintenance (OAM) mechanisms used.

                     BFD is set as a fault detection mechanism,
                     but other mechanisms can be defined in the
                     future.";
                  container bfd {
                    if-feature "vpn-common:bfd";
                    description
                      "Container for BFD.";
                    choice holdtime {
                      default "fixed";
                      description
                        "Choice for holdtime flavor.";
                      case fixed {
                        leaf fixed-value {
                          type uint32;
                          units "msec";
                          description
                            "Expected BFD holdtime.

                             The customer may impose some fixed
                             values for the holdtime period if the
                             provider allows the customer use this
                             function.

                             If the provider doesn't allow the
                             customer to use this function,
                             the fixed-value will not be set.";
                        }
                      }
                      case profile {
                        description
                          "Well-known SP profile.";
                        leaf profile-name {
                          type leafref {
                            path "/l3vpn-ntw/vpn-profiles"
                               + "/valid-provider-identifiers"
                               + "/bfd-profile-identifier/id";
                          }
                          description
                            "Well-known service provider profile name.

                             The provider can propose some profiles
                             to the customer, depending on the
                             service level the customer wants to
                             achieve.";
                        }
                      }
                    }
                    container authentication {
                      presence "Enables BFD authentication";
                      description
                        "Parameters for BFD authentication.";
                      leaf key-chain {
                        type key-chain:key-chain-ref;
                        description
                          "Name of the key-chain.";
                      }
                      leaf meticulous {
                        type boolean;
                        description
                          "Enables meticulous mode.";
                        reference
                          "Section 6.7 of RFC 5880";
                          "RFC 5880: Bidirectional Forwarding
                                     Detection (BFD), Section 6.7";
                      }
                    }
                    uses vpn-common:service-status;
                  }
                }
                container security {
                  description
                    "Site-specific security parameters.";
                  container encryption {
                    if-feature "vpn-common:encryption";
                    description
                      "Container for CE-PE security encryption.";
                    leaf enabled {
                      type boolean;
                      default "false";
                      description
                        "If true, traffic encryption on the
                         connection is required. It is
                         disabled, otherwise.";
                    }
                    leaf layer {
                      when "../enabled = 'true'" {
                        description
                          "Indicates the layer on which encryption
                           is enabled.";
                      }
                      type enumeration {
                        enum layer2 {
                          description
                            "Encryption occurs at Layer 2.";
                        }
                        enum layer3 {
                          description
                            "Encryption occurs at Layer 3.
                             For example, IPsec may be used when
                             a customer requests Layer 3
                             encryption.";
                        }
                      }
                      description
                        "Indicates the layer on which encryption
                         is applied.";
                    }
                  }
                  container encryption-profile {
                    when "../encryption/enabled = 'true'" {
                      description
                        "Indicates the layer on which encryption
                         is enabled.";
                    }
                    description
                      "Container for encryption profile.";
                    choice profile {
                      description
                        "Choice for the encryption profile.";
                      case provider-profile {
                        leaf profile-name {
                          type leafref {
                            path "/l3vpn-ntw/vpn-profiles"
                               + "/valid-provider-identifiers"
                               + "/encryption-profile-identifier/id";
                          }
                          description
                            "Name of the service provider's profile
                             to be applied.";
                        }
                      }
                      case customer-profile {
                        leaf customer-key-chain {
                          type key-chain:key-chain-ref;
                          description
                            "Customer-supplied key chain.";
                        }
                      }
                    }
                  }
                }
                container service {
                  description
                    "Service parameters on of the attachment.";
                  leaf input-bandwidth {
                    type uint64;
                    units "bps";
                    mandatory true;
                    description
                      "From the customer site's perspective, the
                       service input bandwidth of the connection
                       or download bandwidth from the SP to
                       the site.";
                  }
                  leaf output-bandwidth {
                    type uint64;
                    units "bps";
                    mandatory true;
                    description
                      "From the customer site's perspective,
                       the service output bandwidth of the
                       connection or upload bandwidth from
                       the site to the SP.";
                  }
                  leaf mtu {
                    type uint16;
                    units "bytes";
                    mandatory true;
                    description
                      "MTU at service level.  If the service is IP,
                       it refers to the IP MTU.  If CsC is enabled,
                       the requested MTU will refer
                       to the MPLS MTU and not to the IP MTU.";
                  }
                  container qos {
                    if-feature "vpn-common:qos";
                    description
                      "QoS configuration.";
                    container qos-classification-policy {
                      description
                        "Configuration of the traffic classification
                         policy.";
                      uses vpn-common:qos-classification-policy;
                    }
                    container qos-action {
                      description
                        "List of QoS action policies.";
                      list rule {
                        key "id";
                        description
                          "List of QoS actions.";
                        leaf id {
                          type string;
                          description
                            "An identifier of the QoS action rule.";
                        }
                        leaf target-class-id {
                          type string;
                          description
                            "Identification of the class of service.
                             This identifier is internal to the
                             administration.";
                        }
                        leaf inbound-rate-limit {
                          type decimal64 {
                            fraction-digits 5;
                            range "0..100";
                          }
                          units "percent";
                          description
                            "Specifies whether/how to rate-limit the
                             inbound traffic matching this QoS policy.
                             It is expressed as a percent of the value
                             that is indicated in 'input-bandwidth'.";
                        }
                        leaf outbound-rate-limit {
                          type decimal64 {
                            fraction-digits 5;
                            range "0..100";
                          }
                          units "percent";
                          description
                            "Specifies whether/how to rate-limit the
                             outbound traffic matching this QoS policy.
                             It is expressed as a percent of the value
                             that is indicated in 'output-bandwidth'.";
                        }
                      }
                    }
                    container qos-profile {
                      description
                        "QoS profile configuration.";
                      list qos-profile {
                        key "profile";
                        description
                          "QoS profile.
                           Can be standard profile or customized
                           profile.";
                        leaf profile {
                          type leafref {
                            path "/l3vpn-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 carrierscarrier {
                    if-feature "vpn-common:carrierscarrier";
                    description
                      "This container is used when the customer
                       provides MPLS-based services.  This is
                       only used in the case of CsC (i.e., a
                       customer builds an MPLSservice using an
                       IP VPN to carry its traffic).";
                    leaf signalling-type {
                      type enumeration {
                        enum ldp {
                          description
                            "Use LDP as the signalling protocol
                             between the PE and the CE.  In this
                             case, an IGP routing protocol must
                             also be activated.";
                        }
                        enum bgp {
                          description
                            "Use BGP as the signalling protocol
                             between the PE and the CE.
                             In this case, BGP must also be configured
                             as the routing protocol.";
                          reference
                            "RFC 8277: Using BGP to Bind MPLS Labels
                                       to Address Prefixes";
                        }
                      }
                      default "bgp";
                      description
                        "MPLS signalling type.";
                    }
                  }
                  container ntp {
                    description
                      "Time synchronization may be needed in some
                       VPNs such as infrastructure and Management
                       VPNs. This container includes parameters to
                       enable NTP service.";
                    reference
                      "RFC 5905: Network Time Protocol Version 4:
                                 Protocol  and Algorithms
                                 Specification";
                    leaf broadcast {
                      type enumeration {
                        enum client {
                          description
                            "The VPN node will listen to NTP broadcast
                             messages on this VPN network access.";
                        }
                        enum server {
                          description
                            "The VPN node will behave as a broadcast
                             server.";

                        }
                      }
                      description
                        "Indicates NTP broadcast mode to use for the
                         VPN network access.";
                    }
                    container auth-profile {
                      description
                        "Pointer to a local profile.";
                      leaf profile-id {
                        type string;
                        description
                          "A pointer to a local authentication
                           profile on the VPN node is provided.";
                      }
                    }
                    uses vpn-common:service-status;
                  }
                  container multicast {
                    if-feature "vpn-common:multicast";
                    description
                      "Multicast parameters for the network
                       access.";
                    leaf access-type {
                      type enumeration {
                        enum receiver-only {
                          description
                            "The peer site only has receivers.";
                        }
                        enum source-only {
                          description
                            "The peer site only has sources.";
                        }
                        enum source-receiver {
                          description
                            "The peer site has both sources and
                             receivers.";
                        }
                      }
                      default "source-receiver";
                      description
                        "Type of multicast site.";
                    }
                    leaf address-family {
                      type identityref {
                        base vpn-common:address-family;
                      }
                      description
                        "Indicates the address family.";
                    }
                    leaf protocol-type {
                      type enumeration {
                        enum host {
                          description
                            "Hosts are directly connected to the
                             provider network.

                             Host protocols such as IGMP or MLD are
                             required.";
                        }
                        enum router {
                          description
                            "Hosts are behind a customer router.
                             PIM will be implemented.";
                        }
                        enum both {
                          description
                            "Some hosts are behind a customer router,
                             and some others are directly connected
                             to the provider network.  Both host and
                             routing protocols must be used.

                             Typically,  IGMP and PIM will be
                             implemented.";
                        }
                      }
                      default "both";
                      description
                        "Multicast protocol type to be used with
                         the customer site.";
                    }
                    leaf remote-source {
                      type boolean;
                      default "false";
                      description
                        "When true, there is no PIM adjacency on
                         the interface.";
                    }
                    container igmp {
                      when "../protocol-type = 'host' and "
                         + "../address-family = 'vpn-common:ipv4' or "
                         + "'vpn-common:dual-stack'";
                      if-feature "vpn-common:igmp";
                      description
                        "Includes IGMP-related parameters.";
                      list static-group {
                        key "group-addr";
                        description
                          "Multicast static source/group associated to
                           to IGMP session";
                        leaf group-addr {
                          type rt-types:ipv4-multicast-group-address;
                          description
                            "Multicast group IPv4 addresss.";
                        }
                        leaf source-addr {
                          type rt-types:ipv4-multicast-source-address;
                          description
                            "Multicast source IPv4 addresss.";
                        }
                      }
                      leaf max-groups {
                        type uint32;
                        description
                          "Indicates the maximum groups.";
                      }
                      leaf max-entries {
                        type uint32;
                        description
                          "Indicates the maximum IGMP entries.";
                      }
                      leaf max-group-sources {
                        type uint32;
                        description
                          "The maximum number of group sources.";
                      }
                      leaf version {
                        type identityref {
                          base vpn-common:igmp-version;
                        }
                        default "vpn-common:igmpv2";
                        description
                          "Version of the IGMP.";
                      }
                      uses vpn-common:service-status;
                    }
                    container mld {
                      when "../protocol-type = 'host' and "
                         + "../address-family = 'vpn-common:ipv6' or "
                         + "'vpn-common:dual-stack'";
                      if-feature "vpn-common:mld";
                      description
                        "Includes MLD-related parameters.";
                      list static-group {
                        key "group-addr";
                        description
                          "Multicast static source/group associated to
                           the MLD session";
                        leaf group-addr {
                          type rt-types:ipv6-multicast-group-address;
                          description
                            "Multicast group IPv6 addresss.";
                        }
                        leaf source-addr {
                          type rt-types:ipv6-multicast-source-address;
                          description
                            "Multicast source IPv6 addresss.";
                        }
                      }
                      leaf max-groups {
                        type uint32;
                        description
                          "Indicates the maximum groups.";
                      }
                      leaf max-entries {
                        type uint32;
                        description
                          "Indicates the maximum MLD entries.";
                      }
                      leaf max-group-sources {
                        type uint32;
                        description
                          "The maximum number of group sources.";
                      }
                      leaf version {
                        type identityref {
                          base vpn-common:mld-version;
                        }
                        default "vpn-common:mldv2";
                        description
                          "Version of the MLD protocol.";
                      }
                      uses vpn-common:service-status;
                    }
                    container pim {
                      when "../protocol-type = 'router'";
                      if-feature "vpn-common:pim";
                      description
                        "Only applies when protocol type is PIM.";
                      leaf priority {
                        type uint8;
                        description
                          "PIM priority definition.";
                      }
                      leaf hello-interval {
                        type uint8;
                        units "seconds"; rt-types:timer-value-seconds16;
                        default "30";
                        description
                          "PIM hello-messages interval."; interval. If set to
                           'infinity' or 'not-set', no periodic
                           Hello messages are sent.";
                        reference
                          "RFC 7761: Protocol Independent Multicast -
                                     Sparse Mode (PIM-SM): Protocol
                                     Specification (Revised),
                                     Section 4.11";
                      }
                      leaf dr-priority {
                        type uint16; uint32;
                        default "1";
                        description
                          "Value to increase or decrease
                          "Indicates the preference in the
                           chances of a given DR being elected."; election
                           process. Numerically larger DR priority
                           allows a node to be elected as a DR.";
                        reference
                          "RFC 7761: Protocol Independent Multicast -
                                     Sparse Mode (PIM-SM): Protocol
                                     Specification (Revised),
                                     Section 4.3.2";
                      }
                      uses vpn-common:service-status;
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}
<CODE ENDS>

9.  IANA Considerations

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

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

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

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

10.  Security Considerations

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

   The "ietf-l3vpn-ntw" module is used to manage Layer 3 VPNs in a
   service provider backbone network.  Hence, the module can be used to
   request, modify, or retrieve L3VPN services.  For example, the
   creation of a 'vpn-service' leaf instance triggers the creation of an
   L3VPN Service in a service provider network.

   Due to the foreseen use of the "ietf-l3vpn-ntw" module, there

   There are a number of data nodes defined in the this YANG module that are
   writable/creatable/deletable (i.e., config true, which is the
   default).  These data nodes MAY 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-l3vpn-ntw" module:

   o  'vpn-service': An attacker who is able to access network nodes can
      undertake various attacks, such as deleting a running L3VPN
      Service,
      service, interrupting all the traffic of a client.  In addition,
      an attacker may modify the attributes of a running service (e.g.,
      QoS, bandwidth, routing protocols), leading to malfunctioning of
      the service and therefore to SLA violations.  In addition, an
      attacker could attempt to create a an L3VPN Service 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-l3vpn-ntw" this YANG module may be considered
   sensitive or vulnerable in some network environments.  It is thus
   important to control read access (e.g., via get, get-config, or
   notification) to these data nodes.  These are the subtrees and data
   nodes and their sensitivity/vulnerability:

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

   The following summarizes the foreseen risks of using the "ietf-l3vpn-
   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.

11.  Acknowledgements

   During the discussions of this work, helpful comments, suggestions,
   and reviews were received from (listed alphabetically): Raul Arco,
   Miguel Cros Cecilia, Joe Clarke, Adrian Farrel, Roque Gagliano,
   Christian Jacquenet, Kireeti Kompella, and Julian Lucek.  Many thanks
   to them.  Thanks

10.  IANA Considerations

   This document requests IANA to Philip Eardly for register the review of an early version
   of following URI in the document.

   Daniel King, Daniel Voyer, Luay Jalil, and Stephane Litkowski
   contributed to early version of "ns"
   subregistry within the "IETF XML Registry" [RFC3688]:

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

   This work was supported document requests IANA to register the following YANG module in part by
   the European Commission funded
   H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727).

12.  Contributors

   Victor Lopez
   Telefonica
   Email: victor.lopezalvarez@telefonica.com

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

   Manuel Julian
   Vodafone
   Email: manuel-julian.lopez@vodafone.com>

   Lucia Oliva Ballega
   Telefonica
   Email: lucia.olivaballega.ext@telefonica.com>

   Erez Segev
   ECI Telecom
   Email: erez.segev@ecitele.com>

13. "YANG Module Names" subregistry [RFC6020] within the "YANG
   Parameters" registry.

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

11.  References

13.1.

11.1.  Normative References

   [I-D.ietf-opsawg-vpn-common]
              barguil, s., Dios, O., Boucadair, M., and Q. WU, "A Layer
              2/3 VPN Common YANG Model", draft-ietf-opsawg-vpn-
              common-03 (work in progress), January 2021.

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, DOI 10.17487/RFC1112, August 1989,
              <https://www.rfc-editor.org/info/rfc1112>.

   [RFC2080]  Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
              DOI 10.17487/RFC2080, January 1997,
              <https://www.rfc-editor.org/info/rfc2080>.

   [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>.

   [RFC2328]  Moy, J., "OSPF

   [RFC2236]  Fenner, W., "Internet Group Management Protocol, Version
              2", RFC 2236, DOI 10.17487/RFC2236, November 1997,
              <https://www.rfc-editor.org/info/rfc2236>.

   [RFC2453]  Malkin, G., "RIP Version 2", STD 54, 56, RFC 2328, 2453,
              DOI 10.17487/RFC2328, April 10.17487/RFC2453, November 1998,
              <https://www.rfc-editor.org/info/rfc2328>.
              <https://www.rfc-editor.org/info/rfc2453>.

   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710,
              DOI 10.17487/RFC2710, October 1999,
              <https://www.rfc-editor.org/info/rfc2710>.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
              <https://www.rfc-editor.org/info/rfc3376>.

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

   [RFC3810]  Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
              Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
              DOI 10.17487/RFC3810, June 2004,
              <https://www.rfc-editor.org/info/rfc3810>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <https://www.rfc-editor.org/info/rfc4364>.

   [RFC4552]  Gupta, M. and N. Melam, "Authentication/Confidentiality
              for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
              <https://www.rfc-editor.org/info/rfc4552>.

   [RFC4577]  Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the
              Provider/Customer Edge Protocol for BGP/MPLS IP Virtual
              Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577,
              June 2006, <https://www.rfc-editor.org/info/rfc4577>.

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
              <https://www.rfc-editor.org/info/rfc5340>.

   [RFC5701]  Rekhter, Y., "IPv6 Address Specific BGP Extended Community
              Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009,
              <https://www.rfc-editor.org/info/rfc5701>.

   [RFC5709]  Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
              Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
              Authentication", RFC 5709, DOI 10.17487/RFC5709, October
              2009, <https://www.rfc-editor.org/info/rfc5709>.

   [RFC5798]  Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)
              Version 3 for IPv4 and IPv6", RFC 5798,
              DOI 10.17487/RFC5798, March 2010,
              <https://www.rfc-editor.org/info/rfc5798>.

   [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>.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/info/rfc5905>.

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
              June 2010, <https://www.rfc-editor.org/info/rfc5925>.

   [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>.

   [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>.

   [RFC6513]  Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
              BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
              2012, <https://www.rfc-editor.org/info/rfc6513>.

   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
              <https://www.rfc-editor.org/info/rfc6514>.

   [RFC6565]  Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and
              M. Lundberg, "OSPFv3 as a Provider Edge to Customer Edge
              (PE-CE) Routing Protocol", RFC 6565, DOI 10.17487/RFC6565,
              June 2012, <https://www.rfc-editor.org/info/rfc6565>.

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

   [RFC7166]  Bhatia, M., Manral, V., and A. Lindem, "Supporting
              Authentication Trailer for OSPFv3", RFC 7166,
              DOI 10.17487/RFC7166, March 2014,
              <https://www.rfc-editor.org/info/rfc7166>.

   [RFC7474]  Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
              "Security Extension for OSPFv2 When Using Manual Key
              Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
              <https://www.rfc-editor.org/info/rfc7474>.

   [RFC7761]  Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
              Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
              Multicast - Sparse Mode (PIM-SM): Protocol Specification
              (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
              2016, <https://www.rfc-editor.org/info/rfc7761>.

   [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>.

   [RFC7988]  Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress
              Replication Tunnels in Multicast VPN", RFC 7988,
              DOI 10.17487/RFC7988, October 2016,
              <https://www.rfc-editor.org/info/rfc7988>.

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

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

   [RFC8177]  Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J.
              Zhang, "YANG Data Model for Key Chains", RFC 8177,
              DOI 10.17487/RFC8177, June 2017,
              <https://www.rfc-editor.org/info/rfc8177>.

   [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>.

   [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>.

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

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

   [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>.

13.2.

11.2.  Informative References

   [I-D.evenwu-opsawg-yang-composed-vpn]
              Even, R., Bo, W., Wu, Q., and Y. Cheng, "YANG Data Model
              for Composed VPN Service Delivery", draft-evenwu-opsawg-
              yang-composed-vpn-03 (work in progress), March 2019.

   [I-D.ietf-bess-evpn-prefix-advertisement]
              Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A.
              Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf-
              bess-evpn-prefix-advertisement-11 (work in progress), May
              2018.

   [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-10 (work in progress), November 2020.

   [I-D.ietf-pim-yang]
              Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu,
              Y., and f. hu, "A YANG Data Model for Protocol Independent
              Multicast (PIM)", draft-ietf-pim-yang-17 (work in
              progress), May 2018.

   [I-D.ietf-rtgwg-qos-model]
              Choudhary, A., Jethanandani, M., Strahle, N., Aries, E.,
              and I. Chen, "YANG Model for QoS", draft-ietf-rtgwg-qos-
              model-02 (work in progress), July 2020.

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

   [I-D.ietf-teas-ietf-network-slice-definition]

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

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

   [RFC3618]  Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source
              Discovery Protocol (MSDP)", RFC 3618,
              DOI 10.17487/RFC3618, October 2003,
              <https://www.rfc-editor.org/info/rfc3618>.

   [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>.

   [RFC4026]  Andersson, L. and T. Madsen, "Provider Provisioned Virtual
              Private Network (VPN) Terminology", RFC 4026,
              DOI 10.17487/RFC4026, March 2005,
              <https://www.rfc-editor.org/info/rfc4026>.

   [RFC4110]  Callon, R. and M. Suzuki, "A Framework for Layer 3
              Provider-Provisioned Virtual Private Networks (PPVPNs)",
              RFC 4110, DOI 10.17487/RFC4110, July 2005,
              <https://www.rfc-editor.org/info/rfc4110>.

   [RFC4176]  El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K.,
              and A. Gonguet, "Framework for Layer 3 Virtual Private
              Networks (L3VPN) Operations and Management", RFC 4176,
              DOI 10.17487/RFC4176, October 2005,
              <https://www.rfc-editor.org/info/rfc4176>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <https://www.rfc-editor.org/info/rfc4862>.

   [RFC6037]  Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco
              Systems' Solution for Multicast in BGP/MPLS IP VPNs",
              RFC 6037, DOI 10.17487/RFC6037, October 2010,
              <https://www.rfc-editor.org/info/rfc6037>.

   [RFC7149]  Boucadair, M. and C. Jacquenet, "Software-Defined
              Networking: A Perspective from within a Service Provider
              Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
              <https://www.rfc-editor.org/info/rfc7149>.

   [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>.

   [RFC7426]  Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
              Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
              Defined Networking (SDN): Layers and Architecture
              Terminology", RFC 7426, DOI 10.17487/RFC7426, January
              2015, <https://www.rfc-editor.org/info/rfc7426>.

   [RFC7527]  Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E.,
              and W. George, "Enhanced Duplicate Address Detection",
              RFC 7527, DOI 10.17487/RFC7527, April 2015,
              <https://www.rfc-editor.org/info/rfc7527>.

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

   [RFC8277]  Rosen, E., "Using BGP to Bind MPLS Labels to Address
              Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
              <https://www.rfc-editor.org/info/rfc8277>.

   [RFC8299]  Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
              "YANG Data Model for L3VPN Service Delivery", RFC 8299,
              DOI 10.17487/RFC8299, January 2018,
              <https://www.rfc-editor.org/info/rfc8299>.

   [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>.

   [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>.

   [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>.

   [RFC8349]  Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
              Routing Management (NMDA Version)", RFC 8349,
              DOI 10.17487/RFC8349, March 2018,
              <https://www.rfc-editor.org/info/rfc8349>.

   [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>.

   [RFC8512]  Boucadair, M., Ed., Sivakumar, S., Jacquenet, C.,
              Vinapamula, S., and Q. Wu, "A YANG Module for Network
              Address Translation (NAT) and Network Prefix Translation
              (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019,
              <https://www.rfc-editor.org/info/rfc8512>.

   [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.  L3VPN Examples

A.1.  4G VPN Provisioning Example

   L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise
   services mainly because several traffic discrimination policies can
   be applied within the network to deliver to the mobile customers a
   service that meets the SLA requirements.

   As it is shown in the Figure 30, 31, typically, an eNodeB (CE) is
   directly connected to the access routers of the mobile backhaul and
   their logical interfaces (one or many according to the Service service type)
   are configured in a VPN that transports the packets to the mobile
   core platforms.  In this example, a 'vpn-node' is created with two
   'vpn-network-accesses'.

         +-------------+                  +------------------+
         |             |                  | PE               |
         |             | 192.0.2.2                  |  198.51.100.1    |
         |   eNodeB    |>--------/------->|...........       |
         |             |          Vlan          vlan 1  |          |       |
         |             |>--------/------->|......    |       |
         |             |          Vlan          vlan 2  |     |    |       |
         |             | Direct           |  +-------------+ |
         +-------------+ Routing          |  | vpn-node-id | |
                                          |  | 44          | |
                                          |  +-------------+ |
                                          |                  |
                                          +------------------+

                    Figure 30: 31: Mobile Backhaul Example

   To create a an L3VPN service using the L3NM, the following sample steps can be followed:
   followed.

   First: Create the 4G VPN service (Figure 31). 32).

       POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services
       Host: example.com
       Content-Type: application/yang-data+json

       {
         "ietf-l3vpn-ntw:vpn-services": {
           "vpn-service": [
             {
               "vpn-id": "4G",
               "customer-name": "mycustomer",
               "vpn-service-topology": "custom",
               "description": "VPN to deploy 4G services" services",
               "vpn-instance-profiles": {
                 "vpn-instance-profile": [
                   {
                     "profile-id": "simple-profile",
                     "local-autonomous-system": 65550,
                     "rd": "0:65550:1",
                     "address-family": [
                       {
                         "address-family": "vpn-common:dual-stack",
                         "vpn-targets": {
                           "vpn-target": [
                             {
                               "id": "1",
                               "route-targets": [
                                 "0:65550:1"
                               ],
                               "route-target-type": "both"
                             }
                           ]
                         }
                       }
                     ]
                   }
                 ]
               }
             }
           ]
         }
       }

                       Figure 31: 32: Create VPN Service

   Second: Create a VPN node as depicted in Figure 32. 33.  In this type of
   service, the VPN node is equivalent to the VRF configured in the
   physical device ('ne-id'=198.51.100.1).

              POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\
                    vpn-services/vpn-service=4G
              Host: example.com
              Content-Type: application/yang-data+json

              {
                "ietf-l3vpn-ntw:vpn-nodes": {
                  "vpn-node": [
                    {
                      "vpn-node-id": "44",
                      "ne-id": "198.51.100.1",
                      "local-autonomous-system": "65550",
                      "rd": "0:65550:1",
                      "vpn-targets":
                      "active-vpn-instance-profiles": {
                        "vpn-target":
                        "vpn-instance-profile": [
                          {
                            "id": "1",
                            "route-targets": [
                              "0:65550:1"
                            ],
                            "route-target-type": "both"
                            "profile-id": "simple-profile"
                          }
                        ]
                      }
                    }
                  ]
                }
              }

                        Figure 32: 33: Create VPN Node

   Finally, two VPN network accesses are created using the same physical
   port ('port-id'=1/1/1).  Each 'vpn-network-access' has a particular
   VLAN (1,2) to differentiate the traffic between: Sync and data
   (Figure 33). 34).

 POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\
       vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44
 content-type: application/yang-data+json

 {
   "ietf-l3vpn-ntw:vpn-network-accesses": {
     "vpn-network-access": [
       {
              "vpn-network-access-id":
         "id": "1/1/1.1",
         "port-id": "1/1/1",
         "description": "Interface SYNC to eNODE-B",
         "vpn-network-access-type": "vpn-common:point-to-point",
         "vpn-instance-profile": "simple-profile",
         "status": {
           "admin-status": {
             "status": "vpn-common:administrative-state-up"
           }
         },
         "connection": {
           "encapsulation": {
             "type": "dot1q",
             "dot1q": {
               "cvlan-id": 1
             }
           }
         },
              "vpn-network-access-type": "vpn-common:point-to-point",
         "ip-connection": {
           "ipv4": {
             "local-address": "192.0.2.1/32", "192.0.2.1",
             "prefix-length": 30,
             "address-allocation-type": "static-address",
             "static-addresses": {
               "primary-address": "1",
               "address": [
                 {
                   "address-id": "1",
                        "s-customer-address":
                   "customer-address": "192.0.2.2"
                 }
               ]
             }
           },
           "ipv6": {
             "local-address": "2001:db8::1",
             "prefix-length": 64,
             "address-allocation-type": "ietf-l3vpn-ntw:static-address",
             "primary-address": "1",
             "address": [
               {
                 "address-id": "1",
                 "customer-address": "2001:db8::2"
               }
             ]
           }
         },
         "routing-protocols": {
           "routing-protocol": [
             {
               "id": "1",
               "type": "vpn-common:direct"
             }
           ]
         }
       },
       {
              "vpn-network-access-id":
         "id": "1/1/1.2",
         "port-id": "1/1/1",
         "description": "Interface DATA to eNODE-B",
         "vpn-network-access-type": "vpn-common:point-to-point",
         "vpn-instance-profile": "simple-profile",
         "status": {
           "admin-status": {
             "status": "vpn-common:administrative-state-up"
           }
         },
         "connection": {
           "encapsulation": {
             "type": "dot1q",
             "dot1q": {
               "cvlan-id": 2
             }
           }
         },
         "ip-connection": {
           "ipv4": {
             "local-address": "192.0.2.1/32", "192.0.2.1",
             "prefix-length": 30,
             "address-allocation-type": "static-address",
             "static-addresses": {
               "primary-address": "1",
               "address": [
                 {
                   "address-id": "1",
                   "customer-address": "192.0.2.2"
                 }
               ]
             }
                }
           },
              "routing-protocols":
           "ipv6": {
                "routing-protocol":
             "local-address": "2001:db8::1",
             "prefix-length": 64,
             "address-allocation-type": "ietf-l3vpn-ntw:static-address",
             "primary-address": "1",
             "address": [
               {
                    "id":
                 "address-id": "1",
                    "type": "vpn-common:direct"
                  }
                ]
              }
                 "customer-address": "2001:db8::2"
               }
             ]
           }
      }

                   Figure 33: Create VPN Network Access

   Similar actions can be followed when IPv6 is supported in a VPN.  For
   example, Figure 34 illustrates how to create a VPN node that is
   identified with an 'ne-id' set to 2001:db8::1.

              POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\
                    vpn-services/vpn-service=4G
              Host: example.com
              Content-Type: application/yang-data+json

              {
                "ietf-l3vpn-ntw:vpn-nodes": {
                  "vpn-node": [
                    {
                      "vpn-node-id": "44",
                      "ne-id": "2001:db8::1",
                      "local-autonomous-system": "65550",
                      "rd": "0:65550:1",
                      "vpn-targets":
         },
         "routing-protocols": {
                        "vpn-target":
           "routing-protocol": [
             {
               "id": "1",
                            "route-targets": [
                              "0:65550:1"
                            ],
                            "route-target-type": "both"
               "type": "vpn-common:direct"
             }
           ]
         }
       }
     ]
   }
 }

                   Figure 34: Create VPN Node (IPv6) Network Access

A.2.  Loopback Interface

   An example of creating a loopback interface is depicted in . Figure 35.

        {
          "ietf-l3vpn-ntw:vpn-network-accesses": {
            "vpn-network-access": [
              {
                "vpn-network-access-id": "Loopback1",
                "id": "vpn-access-loopback",
                "port-id": "Loopback1",
                "description": "An example of loopback interface.",
                "vpn-network-access-type": "vpn-common:loopback",
                "status": {
                  "admin-status": {
                    "status": "vpn-common:administrative-state-up"
                  }
                },
                "vpn-network-access-type": "vpn-common:loopback",
                "ip-connection": {
                  "ipv6": {
                    "local-address": "2001:db8::1/128" "2001:db8::4",
                    "prefix-length": 128
                  }
                }
              }
            ]
          }
        }

     Figure 35: Create VPN Network Access with a Loopback Interface

A.2. (Message
                                   Body)

A.3.  Multicast VPN Provisioning Example

   IPTV is mainly distributed through multicast over the LANs.  In the
   following example, PIM-SM is enabled and functional between the PE
   and the CE.  The PE receives multicast traffic from a CE that is
   directly connected to the multicast source.  The signaling between PE
   and CE is achieved using BGP.  Also, RP is statically configured for
   a multicast group.

                 +-----------+   +------+     +------+    +-----------+
                 | Multicast |---|  CE  |--/--|  PE  |----|  Backbone |
                 |  source   |   +------+     +------+    |   IP/MPLS |
                 +-----------+                            +-----------+

                Figure 36: Multicast L3VPN Service Example

   To

   An example is provided below to ilustrate how to configure a Multicast
   multicast L3VPN service using the L3NM model the
   procedure and the JSON with the data structure is the following: L3NM.

   First, the multicast service is created together with a generic VPN
   instance profile (see the excerpt of the request message body shown
   in Figure 37)
      {
        "ietf-l3vpn-ntw:vpn-services": {
          "vpn-service": [
            {
              "vpn-id": "Multicast-IPTV",
                  "customer-name": "310",
                  "vpn-service-topology": "vpn-common:hub-spoke",
                  "description":
              "vpn-description": "Multicast IPTV VPN service" service",
              "customer-name": "a-name",
              "vpn-service-topology": "vpn-common:hub-spoke",
              "vpn-instance-profiles": {
                "vpn-instance-profile": [
                  {
                    "profile-id": "multicast",
                    "role": "ietf-vpn-common:hub-role",
                    "local-autonomous-system": 65536,
                    "multicast": {
                      "rp": {
                        "rp-group-mappings": {
                          "rp-group-mapping": [
                            {
                              "id": "1",
                              "rp-address": "203.0.113.17",
                              "groups": {
                                "group": [
                                  {
                                    "id": "1",
                                    "group-address": "239.130.0.0/15"
                                  }
                                ]
                              }
                            }
                          ]
                        },
                        "rp-discovery": {
                          "rp-discovery-type": "vpn-common:static-rp"
                        }
                      }
                    }
                  }
                ]
              }
            }
          ]
        }
      }

      Figure 37: Create Multicast VPN Service (Excerpt of the Message
                               Request Body)

   Then, the VPN nodes are created (see the excerpt of the request
   message body shown in Figure 38).  In this example, the VPN Node node will
   represent VRF configured in the physical device.

   {
     "ietf-l3vpn-ntw:vpn-node": [
       {
         "vpn-node-id": "500003105",
         "description": "VRF-IPTV-MULTICAST",
         "ne-id": "198.51.100.10",
              "node-role": "vpn-common:hub-role",
              "local-autonomous-system": "3816",
              "address-family": "vpn-common:ipv4",
         "router-id": "198.51.100.10",
              "rd": "3816:31050202",
              "multicast": {
                "status": {
                  "admin-status": {
                    "status": "vpn-common:administrative-state-up"
                  }
                },
                "rp": {
                  "rp-group-mappings": {
                    "rp-group-mapping": [
                      {
                        "id": "1",
                        "rp-address": "203.0.113.17",
                        "groups":
         "active-vpn-instance-profiles": {
                          "group":
           "vpn-instance-profile": [
             {
                              "id": "1",
                              "group-address": "239.130.0.0/15"
                            }
                          ]
                        }
               "profile-id": "multicast",
               "rd": "65536:31050202"
             }
           ]
                  },
                  "rp-discovery": {
                    "rp-discovery-type": "vpn-common:static-rp"
                  }
                }
         }
       }
     ]
   }

   Figure 38: Create Multicast VPN Node (Excerpt of the Message Request
                                   Body)

   Finally, create the VPN Network Access network access with multicast enabled (see
   the excerpt of the request message body shown in Figure 39).

   {
     "ietf-l3vpn-ntw:vpn-network-access": {
           "vpn-network-access-id":
       "id": "1/1/1",
       "description": "Connected_to_source", "Connected-to-source",
       "vpn-network-access-type": "vpn-common:point-to-point",
       "vpn-instance-profile": "multicast",
       "status": {
         "admin-status": {
           "status": "vpn-common:administrative-state-up"
         },
           "vpn-network-access-type": "vpn-common:point-to-point",
         "ip-connection": {
           "ipv4": {
             "local-address": "203.0.113.1/32", "203.0.113.1",
             "prefix-length": 30,
             "address-allocation-type": "static-address",
             "static-addresses": {
               "primary-address": "1",
               "address": [
                 {
                   "address-id": "1",
                   "customer-address": "203.0.113.2"
                 }
               ]
             }
           }
         },
         "routing-protocols": {
           "routing-protocol": [
             {
               "id": "1",
               "type": "vpn-common:bgp",
               "bgp": {
                 "description": "Connected to CE"
                   "local-autonomous-system": "3816", CE",
                 "peer-autonomous-system": "6500", "65537",
                 "address-family": "vpn-common:ipv4",
                 "neighbor": "203.0.113.2", "203.0.113.2"
               }
             }
           ]
         },
         "service": {
           "input-bandwidth": "100000000",
           "output-bandwidth": "100000000",
           "mtu": 1500,
           "multicast": {
               "multicast-site-type":
             "access-type": "source-only",
             "address-family": "vpn-common:ipv4",
             "protocol-type": "router",
             "pim": {
               "hello-interval": 30,
               "status": {
                 "admin-status": {
                   "status": "vpn-common:administrative-state-up"
                 }
               }
             }
           }
         }
       }
     }
   }

   Figure 39: Create VPN Network Access (Excerpt of the Message Request
                                   Body)

Appendix B.  Implementation Status

   This section records the status of known implementations of the Yang YANG
   module defined by this specification at the time of posting of this
   Internet-Draft,
   document and is based on a proposal described in [RFC7942].  The
   description of implementations in this section is intended to assist
   the IETF in its decision processes in progressing drafts to RFCs.
   Please note that the listing of any individual implementation here
   does not imply endorsement by the IETF.  Furthermore, no effort has
   been spent to verify the information presented here that was supplied
   by IETF contributors.  This is not intended as, and must not be
   construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   According to [RFC7942], "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see fit".

   Note to the RFC Editor: As per [RFC7942] guidelines, please remove
   this Implementation Status apendix prior publication.

B.1.  Nokia Implementation

   Details can be found at: https://github.com/IETF-OPSAWG-
   WG/l3nm/blob/master/Implementattion/Nokia.txt

B.2.  Huawei Implementation

   Details can be found at: https://github.com/IETF-OPSAWG-
   WG/l3nm/blob/master/Implementattion/Huawei.txt

B.3.  Infinera Implementation

   Details can be found at: https://github.com/IETF-OPSAWG-
   WG/l3nm/blob/master/Implementattion/Infinera.txt

B.4.  Ribbon-ECI Implementation

   Details can be found at: https://github.com/IETF-OPSAWG-
   WG/l3nm/blob/master/Implementattion/Ribbon-ECI.txt

Acknowledgements

   During the discussions of this work, helpful comments, suggestions,
   and reviews were received from (listed alphabetically): Raul Arco,
   Miguel Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque
   Gagliano, Christian Jacquenet, Kireeti Kompella, and Julian Lucek.
   Many thanks to them.  Thanks to Philip Eardly for the review of an
   early version of the document.

   Daniel King, Daniel Voyer, Luay Jalil, and Stephane Litkowski
   contributed to early version of the individual submission.

   This work was supported in part by the European Commission funded
   H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727) and Horizon 2020
   Secured autonomic traffic management for a Tera of SDN flows
   (Teraflow) project (G.A. 101015857).

Contributors

   Victor Lopez
   Telefonica
   Email: victor.lopezalvarez@telefonica.com

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

   Manuel Julian
   Vodafone
   Email: manuel-julian.lopez@vodafone.com

   Lucia Oliva Ballega
   Telefonica
   Email: lucia.olivaballega.ext@telefonica.com

   Erez Segev
   ECI Telecom
   Email: erez.segev@ecitele.com>

   Paul Sherratt
   Gamma Telecom
   Email: paul.sherratt@gamma.co.uk

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

   Mohamed Boucadair (editor)
   Orange
   Rennes 35000
   France

   Email: mohamed.boucadair@orange.com

   Luis Angel Munoz
   Vodafone
   ES

   Email: luis-angel.munoz@vodafone.com

   Alejandro Aguado
   Nokia
   Madrid
   ES

   Email: alejandro.aguado_martin@nokia.com