OPSAWG                                                        S. Barguil
Internet-Draft                                  O. Gonzalez de Dios, Ed.
Intended status: Standards Track                              Telefonica
Expires: October 5, 2020 April 7, 2021                                 M. Boucadair Boucadair, Ed.
                                                                  Orange
                                                                L. Munoz
                                                                Vodafone
                                                               A. Aguado
                                                                   Nokia
                                                          April 03,
                                                         October 4, 2020

                    A Layer 3 VPN Network YANG Model
                     draft-ietf-opsawg-l3sm-l3nm-03
                     draft-ietf-opsawg-l3sm-l3nm-04

Abstract

   This document defines a L3VPN Network YANG Model (L3NM) that can be
   used to manage the provisioning of Layer 3 Virtual Private Network
   (VPN) services within a Service Provider's 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.

   L3NM focuses on BGP PE-based Layer 3 VPNs as described in RFCs 4026,
   4110 and 4364 and Multicast VPNs as described in RFCs 6037, 6513 and
   7988.

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

   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 October 5, 2020. April 7, 2021.

Copyright Notice

   Copyright (c) 2020 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.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  L3NM Reference Architecture . . . . . . . . . . . . . . . . . . .   6
   5.  Relation with other YANG Models . . . . . . . . . . . . . . .   8
   6.  Description  Sample Uses of the L3NM YANG Module Data Model  . . . . . . . . . . . . .  10
     6.1.  Overall Structure of the Module  Enterprise Layer 3 VPN Services . . . . . . . . . . . . .  10
     6.2.  VPN Profiles  Multi-Domain Resource Management  . . . . . . . . . . . .  10
     6.3.  Management of Multicast Services  . . . . . . . . . .  10
     6.3.  Modeling a Layer 3 VPN Service . .  11
   7.  Description of the L3NM YANG Module . . . . . . . . . . .  11
       6.3.1.  Service Status . .  11
     7.1.  Overall Structure of the Module . . . . . . . . . . . . .  11
     7.2.  VPN Profiles  . . . .  12
       6.3.2.  VPN Node . . . . . . . . . . . . . . . . . .  12
     7.3.  Modeling a Layer 3 VPN Service  . . . .  13
         6.3.2.1.  Node Status . . . . . . . . .  13
       7.3.1.  Service Status  . . . . . . . . . .  16
         6.3.2.2.  RT/RD Assignment/auto-assignment . . . . . . . .  16
         6.3.2.3.  VPN Network Access .  15
       7.3.2.  Concept of Import/Export Profiles . . . . . . . . . .  15
       7.3.3.  Underlay Transport  . . . .  17
           6.3.2.3.1.  Connection . . . . . . . . . . . . .  16
       7.3.4.  VPN Node  . . . .  18
           6.3.2.3.2.  IP Connections . . . . . . . . . . . . . . .  22
           6.3.2.3.3.  Security . . .  17
         7.3.4.1.  RT/RD Assignment/auto-assignment  . . . . . . . .  19
         7.3.4.2.  VPN Network Access  . . . . . . .  24
           6.3.2.3.4.  CE PE Routing Protocols . . . . . . . .  20
           7.3.4.2.1.  Connection  . . .  25
           6.3.2.3.5.  Services . . . . . . . . . . . . . .  21
           7.3.4.2.2.  IP Connections  . . . .  29
         6.3.2.4.  Multicast . . . . . . . . . . .  23
           7.3.4.2.3.  Security  . . . . . . . . .  31
       6.3.3.  Concept of Import/Export Profiles . . . . . . . . .  27
           7.3.4.2.4.  CE-PE Routing Protocols .  33
       6.3.4.  Underlay Transport . . . . . . . . . .  27
           7.3.4.2.5.  Services  . . . . . . .  33
   7.  L3NM Module Tree Structure . . . . . . . . . . .  36
         7.3.4.3.  Multicast . . . . . .  33
   8.  Sample Uses of the L3NM Data Model . . . . . . . . . . . . .  43
     8.1.  Enterprise L3 VPN Services .  42
   8.  Layer 3 Network Model . . . . . . . . . . . . . .  43
     8.2.  Multi-Domain Resource Management . . . . . .  43
   9.  IANA Considerations . . . . . .  43
     8.3.  Management of Multicast services . . . . . . . . . . . .  44
   9.  L3VPN Examples . . .  89
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  89
   11. Acknowledgements  .  44
     9.1.  4G VPN Provisioning Example . . . . . . . . . . . . . . .  44
     9.2.  Multicast VPN Provisioning Example . . . . . .  91
   12. Contributors  . . . . .  48
   10. L3NM YANG Module . . . . . . . . . . . . . . . . . . .  91
   13. References  . . .  50
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 110
   12. Security Considerations .  92
     13.1.  Normative References . . . . . . . . . . . . . . . . . . 110
   13. Acknowledgements  92
     13.2.  Informative References . . . . . . . . . . . . . . . . .  93
   Appendix A.  L3VPN Examples . . . . . 112
   14. Contributors . . . . . . . . . . . . . .  96
     A.1.  4G VPN Provisioning Example . . . . . . . . . . 112
   15. References . . . . .  96
     A.2.  Multicast VPN Provisioning Example  . . . . . . . . . . . 100
   Appendix B.  Implementation Status  . . . . . . . . . 113
     15.1.  Normative References . . . . . . . . . . . . . . . . . . 113
     15.2.  Informative References . . . . . . . . . . . . . . . . . 114
   Appendix A.  Implementation Status  . . . . . . . . . . . . . . . 115
     A.1. 104
     B.1.  Nokia Implementation  . . . . . . . . . . . . . . . . . . 115
     A.2. 104
     B.2.  Huawei Implementation . . . . . . . . . . . . . . . . . . 116
     A.3. 104
     B.3.  Infinera Implementation . . . . . . . . . . . . . . . . . 119
     A.4. 104
     B.4.  Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 120 104
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 122 104

1.  Introduction

   [RFC8299] defines an a L3VPN 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 VPN Virtual
   Private Network (VPN) services, and provides an abstracted view of
   the customer's requested services.  That approach limits the usage of
   the L3SM module to the role of a Customer Service Model, according to
   the terminology defined in [RFC8309].

   The YANG data model defined in this

   This document is defined a YANG module called L3VPN Network Model
   (L3NM).  The L3NM module is aimed at providing a network-
   centric network-centric view of L3
   Layer 3 (L3) VPN Services.  The  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, such as resource management or to serve as a
   multi-domain multi-
   domain orchestration interface, where logical resources (such as
   route targets or route distinguishers) must be synchronized.

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

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

   The L3NM YANG module is initially built with a prune and extend
   approach, taking as a starting points the YANG module described in
   [RFC8299].  Nevertheless, this module 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 in the L3NM (e.g., customer) or be used to fed some of
   the L3NM attributes (e.g., actual forwarding policies).  Some of the
   information captured in L3SM may be maintained locally within the
   Orchestrator; which is supposed to maintain a "glue" in charge of maintaining the correspondence
   between a Customer view and its network instantiation.  Likewise,
   some of the information captured and exposed using L3NM can fed the
   service layer (e.g., capabilities) to derive L3SM and drive VPN
   service order handling.

   The L3NM module 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 end-to-
   end VPN connectivity are addressed by a complementary YANG model
   defined in [I-D.evenwu-opsawg-yang-composed-vpn].

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

2.  Requirements Language

   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.

3.  Terminology

   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.

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

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

   This document makes use of the following terms:

   o  L3  Layer 3 VPN Customer Service Model (L3SM): Describes A YANG module that
      describes the requirements of a L3 VPN 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. service provider
      network.  The L3 VPN L3VPN Customer Service model is defined in
      [RFC8299].

   o  L3  Layer 3 VPN Service Network Model (L3NM): A YANG module that
      describes a VPN Service in the Service Provider Network. 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.

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

   o  Network Orchestrator: A functional entity that is hierarchically
      intermediate between Service Orchestrator and Network Controllers.
      A network orchestrator can manage one or several Network
      Controllers.

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

   o  VPN node (vpn-node): node: An abstraction that represents a set of policies applied to
      on a PE and that belong to a single VPN service
      (vpn-service). service.  A vpn-service VPN service
      involves one or more vpn-nodes. VPN nodes.  As it is an abstraction, the
      network controller will take on how to implement a vpn-node. VPN node.  For
      example, typically, in a BGP-based VPN, a vpn-node VPN node could be mapped
      into a VRF. Virtual Routing and Forwarding (VRF).

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

   o  VPN Site (vpn-site): 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].

   o  VPN Service Provider (SP): A Service Provider that offers VPN-related VPN-
      related services [RFC4176].

   o  Service Provider (SP) Network: A network that is able to provide VPN-
      related
      VPN-related services.

4.  L3NM Reference Architecture

   Figure 1 depicts the reference architecture for L3NM.  The figure is
   an expansion of the architecture presented in Section 5 of [RFC8299]
   and decomposes the box marked "orchestration" in that figure into
   three separate functional components called "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].  The above separation relies upon a
   dedicated communication interface between these components and
   appropriate YANG module that reflect network-related information
   (that is hidden to customers).

   The intelligence for translating customer-facing information into
   network-centric one is implementation-specific. 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  |
                            l3vpn-svc        |
                                     +---------------+
                                     |    Service    |
                                     | Orchestration |
                                     +---------------+
                       L3NM Network Model    |
                          l3vpn-ntw          |
                                     +---------------+
                                     |   Network     |
                                     | Orchestration |
                                     +---------------+
               Network Configuration Model   |
                                  __________|____________
                                 +-----------+-----------+
                                 |                       |
                        +---------------+       +---------------+
                        |    Domain     |       |     Domain    |
                        | Orchestration |       | Orchestration |
                        +---------------+       +---------------+
             Device         |        |                   |
             Configuration  |        |                   |
             Model          |        |                   |
                       +---------+   |                   |
                       | Config  |   |                   |
                       | Manager |   |                   |
                       +---------+   |                   |
                            |        |                   |
                            | NETCONF/CLI..................
                            |        |                   |
                     +------------------------------------------------+
                                         Network

                     Figure 1: L3SM and L3NM Reference Architecture

   The L3SM and the L3NM modules may also be set used in the context of the ACTN
   architecture [RFC8453].  Figure 2 shows the Customer Network
   Controller (CNC), the Multi-Domain Service Coordinator (MDSC), and
   the Provisioning Network Controller (PNC).  It also shows the
   interfaces between these functional blocks: the CNC-MDSC Interface
   (CMI), the MDSC-PNC Interface (MPI), and the Southbound Interface
   (SBI).

                  +----------------------------------+
                  | Customer                         |
                  | +-----------------------------+  |
                  | |             CNC             |  |
                  | +-----------------------------+  |
                  +----:-----------------------:-----+
                       :                       :
                       : L3SM                  : L3SM
                       :                       :
             +---------:---------+   +-------------------+
             | MDSC    :         |   |       MDSC        |
             | +---------------+ |   |     (parent)      |
             | |    Service    | |   +-------------------+
             | | Orchestration | |             :
             | +---------------+ |             : L3NM
             |         :         |             :
             |         : L3NM    |   +-------------------+
             |         :         |   |       MDSC        |
             | +---------------+ |   |      (child)      |
             | |    Network    | |   +-------------------+
             | | Orchestration | |             :
             | +---------------+ |             :
              ---------:---------
             +---------:---------+             :
                       :                       :
                       : Network Configuration :
                       :                       :
          +------------:-------+     +---------:------------+
          | 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

   As discussed in the previous section, the L3NM YANG module is meant
   to manage L3VPN Services within a Service Provider network.

   The "ietf-vpn-common" module provides [I-D.ietf-opsawg-vpn-common] includes a network-wise view
   set of the 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 grouping.

   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 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 YANG module is meant to manage
   L3VPN services within a Service Provider network.  The module
   provides a network view of the service.  Such view is only visible
   within the Service Provider and is not exposed outside. 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 (L3NM) may be mapped to an
      external view which is visible to Customers : L3VPN Service YANG
      data Model (L3SM) [RFC8299].

      Typically, the L3NM module can be fed with inputs that are requested by
      Customers, typically, relying upon a 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 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 L3VPN involves nodes that are part of a
      topology managed by the Service Provider Backbone 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]) [RFC8349].

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

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

      *  NAT management ([RFC8512]) [RFC8512].

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

      *  ACL ([RFC8519])  ACLs [RFC8519].

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

6.  Description  Sample Uses of the L3NM YANG Module

   The L3NM module ('ietf-l3vpn-ntw') is meant to manage L3 VPNs in a
   service provider network.  In particular, Data Model

6.1.  Enterprise Layer 3 VPN Services

   Enterprise L3VPNs are one of the 'ietf-l3vpn-ntw' module most demanded services for carriers,
   and therefore, L3NM can be used useful to create, modify, automate the tasks of
   provisioning and retrieve L3VPN Services maintenance of these VPNs.  Templates and batch
   processes can be built, and as a
   network.

   The detailed tree structure is provided in Figure 17.

6.1.  Overall Structure result many parameters are needed
   for the creation from scratch of a VPN that can be abstracted to the Module

   The 'ietf-l3vpn-ntw' module uses two main containers: 'vpn-services'
   upper SDN layer and 'vpn-profiles' (see Figure 3).

   The 'vpn-services' container maintains the set little manual intervention will be still
   required.

   Also common addition/removal of sites of an existing customer VPN services
   managed within the service provider's network. 'vpn-service' is the
   data structure that abstracts a VPN service (Section 6.3).

   The 'vpn-profiles' container is used can
   benefit of using L3NM, by the provider to maintain a
   set creation of common VPN profiles workflows that apply to several VPN services
   (Section 6.2).

   module: ietf-l3vpn-ntw
     +--rw l3vpn-ntw
        +--rw vpn-profiles
        |  ...
        +--rw vpn-services
            +--rw vpn-service* [vpn-id]
               ...

                   Figure 3: Overall L3NM Tree Structure either prune or
   add nodes as required from the network data model object.

6.2.  VPN Profiles  Multi-Domain Resource Management

   The 'vpn-profiles' containers (Figure 4) allow 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 provider resources to define and maintain a set of common VPN profiles be synchronized between systems.
   Particularly, there are two resources that apply must be orchestrated and
   manage to
   several VPN services.  The exaact definition of avoid asymmetric (non-functional) configuration, or the profiles
   usage of unavailable resources.

   For example, RTs shall be synchronized between PEs.  When every PE is local
   controlled by the same management system, RT allocation can be
   performed by the system.  In cases where the service spans across
   multiple management systems, this task of allocating RTs has to each network provider.

       +--rw l3vpn-ntw
          +--rw vpn-profiles
          |  +--rw valid-provider-identifiers
          |     +--rw cloud-identifier* [id] {l3vpn-svc:cloud-access}?
          |     |  +--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 routing-profile-identifier* [id]
          |        +--rw id    string
          +--rw vpn-services
              +--rw vpn-service* [vpn-id]
                 ...

                   Figure 4: VPN Profiles Tree Structure

6.3.  Modeling a Layer 3 VPN Service

   The 'vpn-service' is be
   aligned across the data structure that abstracts domains, therefore, the service model must provide
   a VPN Service way to specify RTs.  In addition, RDs must also be synchronized to
   avoid collisions in RD allocation between separate systems.  An
   incorrect allocation might lead to the Service Provider Network.  Each 'vpn-service' is uniquely
   identified same RD and IP prefixes being
   exported by an identifier: 'vpn-id'.  Such 'vpn-id' is only
   meaningful locally within different PE routers.

6.3.  Management of Multicast Services

   Multicast services over L3VPN can be implemented either using dual
   PIM MVPNs (also known as, Draft Rosen model) [RFC4364] or
   multiprotocol BGP (MBGP)-based MVPNs[RFC6513][RFC6514].  Both methods
   are supported and equally effective, but the Network controller.

   In order to facilitate main difference is that
   MBGP-based MVPN does not require multicast configuration on the identification of
   service provider backbone.  MBGP MVPNs employ the service, 'customer-
   name' intra-autonomous
   system BGP control plane and 'description' attributes may be provided. PIM sparse mode as the data plane.  The 'vpn-service' parameters are:

   o  'service-status': Allows
   PIM state information is maintained between the PE routers using the
   same architecture that is used for unicast VPNs.

   On the other hand, Draft Rosen has limitations such as reduced
   options for transport, control plane scalability, availability,
   operational inconsistency, and the need of maintaining state in the operative and
      administrative status
   backbone.  Because of this, MBGP MVPN is the service as a whole.

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

   o  'l3sm-vpn-id': Refers to an identifier of L3SM service.  This
      identifier allows to easily correlate the (network) service
   has been taken as
      built in the network with a service order.

   o  'vpn-service-topology': Indicates the network topology base for the
      service: Hub-Spoke, Any-to-Any, implementing multicast service on
   L3VPN.  In this scenario, BGP auto discovery is used to discover MVPN
   PE members and Custom. the customer PIM signaling is sent across provider
   core through MP-BGP.  The deployment multicast traffic is transported on MPLS
   P2MP LSPs.  All of the
      network previous information is defined by carried in the correct usage MCAST-
   VPN BGP NRLI.

7.  Description of import and export
      profiles

   o  'ie-profiles': Defines reusable import/export policies for the
      same 'vpn-service'.  More details are provided L3NM YANG Module

   The L3NM ('ietf-l3vpn-ntw') is defined to manage L3VPNs in Section 6.3.3

   o  'underlay-transport': Describes the preference for a service
   provider network.  In particular, the transport
      technology 'ietf-l3vpn-ntw' module can be
   used to carry the traffic create, modify, and retrieve L3VPN Services of a network.

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-services' container maintains the set of VPN service.

   A VPN services
   managed within the service provider's network. 'vpn-service' is typically built by adding instances of 'vpn-node' to the 'vpn-nodes' container.
   data structure that abstracts a VPN service (Section 7.3).

   The 'vpn-node' 'vpn-profiles' container is an abstraction that
   represents used by the provider to maintain a
   set of policies applied to a network node and common VPN profiles that
   belong to a single 'vpn-service'.

   A 'vpn-node' contains 'vpn-network-accesses', which are the
   interfaces attached apply 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 model.

   +--rw vpn-service* [vpn-id]
      +--rw service-status
      |  ...
      +--rw vpn-id                  l3vpn-svc:svc-id
      +--rw l3sm-vpn-id?            l3vpn-svc:svc-id
      +--rw customer-name?          string
      +--rw vpn-service-topology?   identityref
      +--rw description?            string
      +--rw ie-profiles
      |  ...
      +--rw underlay-transport
      |  ...

                   Figure 5: vpn-service tree structure

6.3.1.  Service Status

   The L3NM module allows to track service status ('service-status') of
   a given one or several VPN service (Figure 6).  Both operational and administrative
   status are maintained together with a timestamp.  For example, a
   service can be created but not put into effect.

   'admin' and 'ops' status can be used as trigger to detect service
   anomalies.  For example, a service that is declared at the service
   layer as active but still inactive at the network layer is an
   indication that network provision actions are needed to align the
   observed service with the expected service status. services
   (Section 7.2).

   module: ietf-l3vpn-ntw
     +--rw l3vpn-ntw
        +--rw vpn-profiles
        |  ...
        +--rw vpn-services
            +--rw vpn-service* [vpn-id]
              +--rw service-status
              |  +--rw admin
              |  |  +--rw status?      operational-type
              |  |  +--rw timestamp?   yang:date-and-time
              |  +--ro ops
              |     +--ro status?      operational-type
              |     +--ro timestamp?   yang:date-and-time
               ...

                   Figure 6: VPN Service Status 3: Overall L3NM Tree Structure

6.3.2.

7.2.  VPN Node Profiles

   The 'vpn-node' is an abstraction that represents 'vpn-profiles' container (Figure 4) allows the network provider
   to define and maintain a set of common
   policies applied on a given network node (tipcally, a PE) and belong VPN profiles
   [I-D.ietf-opsawg-vpn-common] that apply to one L3 or several VPN service.  In order to indicate
   services.  The exact definition of the profiles is local to each
   network nodes where
   the 'vpn-node' applies, provider.

   This document does not make any assumption about the 'ne-id' must be indicated. exact definition
   of these profiles.  How such profiles are defined is deployment
   specific.  The 'vpn-
   node' model only includes a parameter an identifier to indicate the network node on which it
   is applied.  In the case that the 'ne-id' points these profiles to
   ease identifying local policies when building a specific PE,
   the 'vpn-node' will likely be mapped into a VRF VPN service.  As
   shown in Figure 4, the node.
   However, the model also allows to point to an abstract node.  In this
   case, the network controller will decide how following identifiers can be included:

   o  'cloud-identifier': This identifier refers to split the 'vpn-node'
   into VRFs.  Soem 'vpn-node' parameters are listed below: a cloud service.

   o  local-autonomous-system: Refers  'encryption-profile-identifier': An encryption profile refers to a
      set of policies related to the autonomous system number encryption scheme(s) and setup that is locally configured in the instance.  It
      can be overwritten
      for specific purposes in the CE-PE BGP session.

   o  maximum-routes: Set the maximum number of prefixes allowed in the
      'vpn-node' instance.  This value is typically set in the service
      request.

   o  'rd' applied when building and 'vpn-targets': For the cases the logical resources are
      managed outside the network controller, the model allows offering a VPN service.

   o  'qos-profile-identifier': A QoS profile refers to
      explicitely indicate the logical resources as set of
      policies such as Route targets
      (RTs) classification, marking, and Route Distinguishers (RDs) (RT,RD). actions (e.g.,
      [RFC3644]).

   o  Multicast: Enable multicast traffic inside the VPN.  Refer  'bfd-profile-identifier': A Bidirectional Forwarding Detection
      (BFD) profile refers to
      Section 6.3.2.4.

   Under the VPN Node ('vpn-node') container, VPN Network Acesses ('vpn-
   network-access') a set of BFD [RFC5880] policies that can
      be created.  The invoked when building a VPN Network Acess represents
   the point to which sites are connected.  Note that, unlike in L3SM,
   the L3NM does not need service.

   o  'forwarding-profile-identifier': A forwarding profile refers to model the customer site, only the points
   where the traffic from the site are received.  Hence, the VPN Network
   access contains
      the connectivity information between the provider's
   network and policies that apply to the customer premises.  The VPN profiles ('vpn-profiles')
   have forwarding of packets conveyed
      within a VPN.  Such policies may consist at applying Access
      Control Lists (ACLs).

   o  'routing-profile-identifier': A routing profile refers to a set of
      routing policies than can that will be applied during the service
   creation.

   module: ietf-l3vpn-ntw invoked (e.g., BGP policies).

            +--rw l3vpn-ntw
               +--rw vpn-profiles
               |  ...
      +--rw vpn-services
       +--rw vpn-service* [vpn-id]
          +--rw vpn-id                  l3vpn-svc:svc-id
          + ...
          +--rw vpn-nodes
           +--rw vpn-node* [ne-id]
              +--rw vpn-node-id?               union
              +--rw local-autonomous-system?   inet:as-number
              +--rw description?               string
              +--rw ne-id                      string
              +--rw router-id?                 inet:ip-address
              +--rw address-family?
              |       l3vpn-svc:address-family
              +--rw node-role?                 identityref
              +--rw rw rd?                        union  +--rw vpn-targets valid-provider-identifiers
               |     +--rw vpn-target* cloud-identifier* [id] {cloud-access}?
               |     |  +--rw id                   int8
              |    string
               |     +--rw route-targets* [route-target]
              | encryption-profile-identifier* [id]
               |     |  +--rw route-target
              |  |  |          rt-types:route-target
              | id    string
               |     +--rw route-target-type
              |  |          rt-types:route-target-type qos-profile-identifier* [id]
               |  +--rw vpn-policies     |  +--rw import-policy?   leafref id    string
               |     +--rw export-policy?   leafref
              +--rw status bfd-profile-identifier* [id]
               |  +--rw admin-enabled?   boolean     |  +--ro oper-status?     operational-type  +--rw vpn-network-accesses id    string
               |     +--rw vpn-network-access* forwarding-profile-identifier* [id]
               |     +--rw id
              |     |       l3vpn-svc:svc-id
              |     ...
              +--rw maximum-routes     |  +--rw address-family* [af] id    string
               |     +--rw af
              |     |       l3vpn-svc:address-family routing-profile-identifier* [id]
               |        +--rw maximum-routes?   uint32 id    string
               +--rw multicast {l3vpn-svc:multicast}?
              | vpn-services
                  ...
              +--rw node-ie-profile?           leafref

                 Figure 7: 4: VPN Node Tree Profiles Subtree Structure

6.3.2.1.  Node Status

7.3.  Modeling a Layer 3 VPN Service

   The L3NM module allows to track the status ('status') of 'vpn-service' is the nodes
   involved in data structure that abstracts a VPN service (Figure 8).  Both operational and
   administrative status are maintained.  Mismatch between an
   administrative status vs.
   in the operational status can be used as
   trigger 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.

   In order to detect anomalies.

     +--rw l3vpn-ntw
        +--rw vpn-profiles
        |  ...
        +--rw vpn-services
           +--rw vpn-service* [vpn-id]
              +--rw vpn-id                  l3vpn-svc:svc-id
              ...
              +--rw vpn-nodes
              |  +--rw vpn-node* [ne-id]
              |     +--rw ne-id                   string
              |     ...
              |     +--rw status
              |     |  +--rw admin-enabled?   boolean
              |     |  +--ro oper-status?     operational-type

                   Figure 8: Node Status Tree Structure

6.3.2.2.  RT/RD Assignment/auto-assignment

   For facilitate the cases identification of the logical resources are managed outside service, 'customer-
   name' and 'description' attributes may be provided.

   The main 'vpn-service' parameters are:

   o  'status': Allows the network
   controller, control of the model allows to explicitely indicate operative and administrative
      status of the logical
   resources such service as Route targets (RTs) and Route Distinguishers (RDs)
   (RT,RD).

   Three possible behaviors are needed a whole.

   o  'vpn-id': Is an identifier that is used to fulfil uniquely identify the identified use
   cases:
      L3VPN Service within L3NM scope.

   o  The network controller auto-assigns logical resources (RTs, RDs).  'l3sm-vpn-id': Refers to an identifier of L3SM service.  This can apply for new services deployment.

   o  The Network Operator/Service orchestrator assigns explicitly
      identifier allows to easily correlate the
      RTs and RDs.  This case will fit (network) service as
      built in the network with a brownfield scenario where
      some existing services needs to be updated by service order.

   o  'vpn-service-topology': Indicates the network
      operators.

   o topology for the
      service: Hub-Spoke, Any-to-Any, and Custom.  The Network Operator/Service orchestrator explicitly wants NO RT/
      RD to be assigned.  This case will fit in VRF-Lite scenarios, CE
      testing inside deployment on the Network or just for troubleshooting pruposes.

   Thus a union between two yang data types are included in order to
   support this scenarios.  So, if the leaf
      network is not created in the Yang defined by the expected behavior is correct usage of import and export
      profiles

   o  'vpn-type': Indicate the auto-assigns.  If VPN service signaling type.

   o  'ie-profiles': Defines reusable import/export policies for the Leaf is created
   with a valid rd value it will be explicitly assign
      same 'vpn-service'.  More details are provided in Section 7.3.2.

   o  'underlay-transport': Describes the VPN Node
   and if preference for the leaf is created with an empty value, transport
      technology to carry the RD value will not
   be deployed in traffic of the VPN node.

6.3.2.3.  VPN Network Access

   A 'vpn-network-access' represents service
      (Section 7.3.3).

   The 'vpn-node' is an entry point abstraction that represents a set of policies
   applied to a VPN service
   (Figure 9).  In other words, this container encloses the parameters
   that describe the access information for the traffic network node and that belongs belong to a particular L3VPN.  As such, every 'vpn-network-access' MUST belong single 'vpn-service'.
   A VPN service is typically built by adding instances of 'vpn-node' to one and only one 'vpn-node'.
   the 'vpn-nodes' container.

   A 'vpn-network-access' includes information such as 'vpn-node' contains 'vpn-network-accesses', which are the connection on
   interfaces attached to the VPN by which the access customer traffic is defined (see Section 6.3.2.3.1), the
   encapsulation of
   received.  Therefore, the traffic, policies that customer sites are applied on connected to the
   access, etc.

   A provisioning Network Controller (PNC) [RFC8453] will accept VPN
   requests containing 'vpn-
   network-accesses'.

   Note that, as this construct, using the enclosed is a network data to:
   configure model, the router's interface to include information about
   customers sites is not required in the parameters described
   at the 'vpn-network-access', include the given interface into a VRF,
   configuring policies or schedulers for processing model.  Such information is
   rather relevant in the incoming
   traffic, etc.

   module: ietf-l3vpn-ntw L3SM.

     +--rw l3vpn-ntw
        +--rw vpn-profiles
        |  ...
        +--rw vpn-services
           +--rw vpn-service* [vpn-id]
              +--rw vpn-id                  l3vpn-svc:svc-id
          + status
              |  ...
              +--rw vpn-node* [ne-id] vpn-id                  vpn-common:vpn-id
              +--rw ne-id vpn-name?               string
              + ...
              +--rw vpn-network-accesses
              |  +--rw vpn-network-access* [id]
              |     +--rw id
              |     |       l3vpn-svc:svc-id
              |
              +--rw port-id?
              |     |       l3vpn-svc:svc-id
              | vpn-description?        string
              +--rw description? customer-name?          string
              |
              +--rw status
              |     | l3sm-vpn-id?            vpn-common:vpn-id
              +--rw admin-enabled?   boolean
              |     |  +--ro oper-status?     operational-type
              | vpn-type?               identityref
              +--rw vpn-network-access-type? vpn-service-topology?   identityref
              |
              +--rw connection
              | ie-profiles
              |  ...
              |     |
              +--rw bearer
              | underlay-transport
              |  ...
              |
              +--rw ip-connection
              |     | vpn-nodes
                 ...
              |

                 Figure 5: VPN Services Subtree Structure

7.3.1.  Service Status

   The L3NM allows to track service status ('status') of a given VPN
   service (Figure 6).  Both operational and administrative status are
   maintained together with a timestamp.  For example, a service can be
   created but not put into effect.

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

     +--rw security
              | l3vpn-ntw
        +--rw vpn-profiles
        |  ...
        +--rw vpn-services
           +--rw vpn-service* [vpn-id]
              +--rw status
              |  +--rw routing-protocols admin-status
              |  |  ...  +--rw status?         identityref
              |  |  +--rw service last-updated?   yang:date-and-time
              |        ...  +--ro oper-status
              |     +--ro status?         identityref
              |     +--ro last-updated?   yang:date-and-time
              ...

              Figure 9: 6: VPN Network Access Tree Service Status Subtree Structure

6.3.2.3.1.  Connection

   The definition

7.3.2.  Concept of Import/Export Profiles

   The import and export profiles construct contains a L3VPN list with
   information related with route target and distinguishers (RTs and
   RDs), grouped and identified by 'ie-profile-id'.  The identifier is commonly specified not only at
   then referenced in one or multiple 'vpn-nodes' so the IP
   layer, but also requires to controller can
   identify parameters at the Ethernet
   layer, such as encapsulation type (e.g., VLAN, QinQ, QinAny, VxLAN,
   etc.).  The 'connection' container represents RTs and groups the set of
   L2 connectivity from where the traffic of the L3VPN in RDs to be configured for a particular
   VPN Network access is coming.

   Additionally, the bearer-reference and the pseudowire termination are
   supported.

   Ethernet encapsulation description given VRF.  The subtree
   is not supported shown in [RFC8299].
   However, this parameters are mandatory to configure the PE
   interfaces.  Thus, In the L3NM, these parameters uses the connection
   container inside the vpn-network-access.  This container defines
   protocols and parameters to enable connectivity at Layer 2.

   module: ietf-l3vpn-ntw Figure 7.

     +--rw l3vpn-ntw
        +--rw vpn-profiles
        |  ...
        +--rw vpn-services
           +--rw vpn-service* [vpn-id]
              +--rw vpn-id                  l3vpn-svc:svc-id
          +  ...
           +--rw vpn-node* [ne-id]
              +--rw ne-id                      string                  vpn-common:vpn-id
              +  ...
              +--rw vpn-network-accesses ie-profiles
              |  +--rw vpn-network-access* [id] ie-profile* [ie-profile-id]
              |     +--rw id
              |     |       l3vpn-svc:svc-id
              |     + ... ie-profile-id    string
              |     +--rw connection
              | rd?              union
              |     +--rw encapsulation-type?   identityref
              | vpn-targets
              |        +--rw logical-interface
              | vpn-target* [id]
              |        |  +--rw peer-reference?   uint32 id                   int8
              |        |  +--rw tagged-interface route-targets* [route-target]
              |        |  |  +--rw type?                identityref
              | route-target    rt-types:route-target
              |        |  +--rw dot1q-vlan-tagged {dot1q}?
              | route-target-type
              |        |          rt-types:route-target-type
              |        +--rw tag-type?   identityref
              |     |  | vpn-policies
              |           +--rw cvlan-id?   uint16
              |     | import-policy?   string
              |           +--rw priority-tagged
              |     |  |  | export-policy?   string
              +--rw tag-type?   identityref
              |     |  | vpn-nodes
                 +--rw qinq {qinq}?
              |     |  |  | vpn-node* [ne-id]
                    +--rw tag-type?   identityref
              |     |  |  | ne-id                      string
                    ...
                    +--rw svlan-id    uint16
              |     |  | vpn-targets
                    |  +--rw cvlan-id    uint16
              | vpn-target* [id]
                    |  |  +--rw qinany {qinany}?
              |     | id                   int8
                    |  |  +--rw tag-type?   identityref
              | route-targets* [route-target]
                    |  |  |  +--rw svlan-id    uint16
              | route-target    rt-types:route-target
                    |  |  +--rw vxlan {vxlan}? route-target-type
                    |  |          rt-types:route-target-type
                    |  +--rw vni-id       uint32
              |     | vpn-policies
                    |     +--rw peer-mode?   identityref
              |     | import-policy?   string
                    |     +--rw peer-list* [peer-ip]
              |     |  |        +--rw peer-ip    inet:ip-address
              |     |  +--rw bearer
              |     |     ...
              |     +--rw ip-connection
              |     |  ...
              |     +--rw security
              |     |  ...
              |     +--rw routing-protocols
              |     |  ...
              |     +--rw service
              |        ...
              | export-policy?   string
                    ...

           Figure 10: Encapsulation Tree 7: Subtree Structure

   Depending on the control plane implementation, different network
   scenarios might require additional information of Import/Export Profiles

7.3.3.  Underlay Transport

   The model allows to indicate a preference for the underlay transport
   technology when activating a L3VPN service
   to be configured and active.  For example, an L3VPN Option C service,
   if no reflection of IPv4 VPN routes is configured via ASBR or route
   reflector, may require additional configuration (e.g., a new BGP
   neighbor) to be coordinated between both management systems. (Figure 8).  This
   definition requires for every management system participant
   preference is especially useful in networks with multiple domains and
   NNI types.  This version of the
   VPN to receive not just their own sites YANG module supports these options:
   BGP, LDP, GRE, SR, SR-TE, and site-network-accesses,
   but also to receive information about external ones, identified RSVP-TE as an
   external site-network-access-type.  In addition, this particular
   site-network-access is augmented to include the loopback address of underlay transport
   mechanisms.  Other profiles can be defined in the far-end (remote/external) PE router.

   module: ietf-l3vpn-ntw future.

     +--rw l3vpn-ntw
        +--rw vpn-profiles
        |  ...
        +--rw vpn-services
           +--rw vpn-service* [vpn-id]
              +--rw vpn-id                  l3vpn-svc:svc-id
          +  ...
           +--rw vpn-node* [ne-id]
              +--rw ne-id                      string
              + ...
              +--rw vpn-network-accesses
              |  +--rw vpn-network-access* [id]
              |     +--rw id
              |     |       l3vpn-svc:svc-id
              |                  vpn-common:vpn-id
              +  ...
              |     +--rw connection
              |     |  ...
              |     |  +--rw bearer
              |     |     +--rw bearer-reference?   string
              |     |     |       {l3vpn-svc:bearer-reference}?
              |     |     +--rw pseudowire
              |     |     |  +--rw vcid?      uint32
              |     |     |  +--rw far-end?   union
              |     |
              +--rw vpls
              | underlay-transport
              |  +--rw vcid?      union
              |     | type*   identityref
              +--rw far-end?   union
              | vpn-nodes
                 +--rw ip-connection
              |     |  ...
              |     +--rw security
              |     |  ...
              |     +--rw routing-protocols
              |     |  ...
              |     +--rw service
              |        ...
              | vpn-node* [ne-id]
                 ...

          Figure 11: Bearer Tree 8: Subtree Structure

   A site, as per [RFC4176] represents a of the Underlying Transport

7.3.4.  VPN customer's location that Node

   The 'vpn-node' is
   connected to the Service Provider an abstraction that represents a set of common
   policies applied on a given network via node (tipcally, a CE-PE link, which can
   access at least PE) and belong
   to one VPN.  The connection from the site L3VPN service.  In order to indicate the Service
   Provider network is the bearer.  Every site is associated with a list
   of bearers.  A bearer is nodes where
   the layer two connections with 'vpn-node' applies, the site.  In 'ne-id' must be indicated.  The 'vpn-
   node' includes a parameter to indicate the module network node on which it
   is assumed that the bearer has been allocated by applied.  In the
   Service Provider at case that the service orchestration step.  The bearer is
   associated 'ne-id' points to a network element and a port.  Hence, a bearer is just specific PE,
   the 'vpn-node' will likely be mapped into a bearer-reference VRF in the node.
   However, the model also allows to allow point to an abstract node.  In this
   case, the translation between L3SM and L3NM.

6.3.2.3.2.  IP Connections

   IP connection container (Figure 12) has network controller will decide how to split the 'vpn-node'
   into VRFs.  Some 'vpn-node' parameters of are listed below:

   o  local-autonomous-system: Refers to the 'vpn-
   network-access' addressing information.  The address allocated autonomous system number
      that is locally configured in
   this container would represent the PE interface address
   configuration.  The IP connection container is designed to support
   both IPv4 and IPv6. instance.  It also supports three options for IP address
   assignment: Provider DHCP, DHCP relay, and static addressing.

   In can be overwritten
      for specific purposes in the case CE-PE BGP session.

   o  maximum-routes: Set the maximum number of prefixes allowed in the static addressing,
      'vpn-node' instance.  This value is typically set in the service
      request.

   o  'rd' and 'vpn-targets': For the cases the logical resources are
      managed outside the network controller, the model supports allows to
      explicitely indicate the
   assignment of several IP addresses in logical resources such as Route targets
      (RTs) and Route Distinguishers (RDs) (RT,RD).

   o  Multicast: Enable multicast traffic inside the same 'vpn-network-access'.
   To identify VPN.  Refer to
      Section 7.3.4.3.

   Under the VPN Node ('vpn-node') container, VPN Network Accesses
   ('vpn-network-access') can be created.  The VPN Network Access
   represents the point to which of sites are connected.  Note that, unlike
   in L3SM, the addresses is L3NM does not need to model the primary address customer site, only the
   points where the traffic from the site are received (i.e., the PE
   side of PE-CE connections).  Hence, the VPN Network access contains
   the connectivity information between the provider's network and the
   customer premises.  The VPN profiles ('vpn-profiles') have a
   connection ,the "primary-address" reference MUST be set with of
   routing policies than can be applied during the
   corresponding 'address-id'.

   module: ietf-l3vpn-ntw service creation.

   The L3NM allows to track the status ('status') of the nodes involved
   in a VPN service.  Both operational and administrative status are
   maintained.  Mismatch between an administrative status vs.  the
   operational status can be used as trigger to detect anomalies.

     +--rw l3vpn-ntw
        +--rw vpn-profiles
        |  ...
        +--rw vpn-services
           +--rw vpn-service* [vpn-id]
              +--rw vpn-id                  l3vpn-svc:svc-id
          +                  vpn-common:vpn-id
              ...
              +--rw vpn-nodes
                 +--rw vpn-node* [ne-id]
                    +--rw ne-id vpn-node-id?               union
                    +--rw local-autonomous-system?   inet:as-number
                    +--rw description?               string
              +  ...
                    +--rw status
              | ne-id                      string
                    +--rw admin-enabled?   boolean
              |  +--ro oper-status?     operational-type router-id?                 inet:ip-address
                    +--rw vpn-network-accesses address-family?
                    |       vpn-common:address-family
                    +--rw vpn-network-access* [id]
              |     +--rw id
              |     |       l3vpn-svc:svc-id
              |     +  ...
              |     +--rw connection
              |     |  ...
              |     +--rw ip-connection
              |     |  +--rw ipv4 {l3vpn-svc:ipv4}?
              |     |  |  +--rw address-allocation-type?
              |     |  |  | node-role?                 identityref
              |     |  |  +--rw provider-dhcp
              |     |  |  |  +--rw provider-address?
              |     |  |  |  |       inet:ipv4-address
              |     |  |  |
                    +--rw prefix-length?
              |     |  |  |  |       uint8
              |     |  |  | rd?                        union
                    +--rw (address-assign)?
              |     |  |  |     +--:(number)
              |     |  |  | vpn-targets
                    |  +--rw number-of-dynamic-address?
              |     |  |  |     |          uint16
              |     |  |  |     +--:(explicit)
              |     | vpn-target* [id]
                    |  |  +--rw customer-addresses
              |     | id                   int8
                    |  |  +--rw address-group*
              |     |  |  |                   [group-id]
              | route-targets* [route-target]
                    |  |  |  +--rw group-id
              |     |  |  |              |       string
              |     | route-target    rt-types:route-target
                    |  |  +--rw start-address?
              |     |  |  |              |       inet:ipv4-address
              | route-target-type
                    |  |          rt-types:route-target-type
                    |  +--rw end-address?
              |     |  |  |                      inet:ipv4-address
              |     | vpn-policies
                    |     +--rw dhcp-relay
              |     |  | import-policy?   string
                    |     +--rw provider-address?
              |     |  |  |  |       inet:ipv4-address
              |     |  |  | export-policy?   string
                    +--rw prefix-length?           uint8
              |     |  | status
                    |  +--rw customer-dhcp-servers
              |     | admin-status
                    |  |  +--rw server-ip-address*
              |     |  |  |             inet:ipv4-address
              | status?         identityref
                    |  |  +--rw static-addresses last-updated?   yang:date-and-time
                    |  +--ro oper-status
                    |     +--ro status?         identityref
                    |     +--ro last-updated?   yang:date-and-time
                    +--rw primary-address? node-ie-profile?           leafref
              |     |  |
                    +--rw address* [address-id]
              |     | groups
                    |  +--rw address-id          string
              |     | group* [group-id]
                    |     +--rw provider-address?
              |     |  |        |       inet:ipv4-address
              |     |  | group-id    string
                    +--rw customer-address?
              |     |  |        |       inet:ipv4-address
              |     | vpn-network-accesses
                    |  +--rw prefix-length?      uint8
              | vpn-network-access* [id]
                    |     ...
                    +--rw ipv6 {l3vpn-svc:ipv6}?
              |     | maximum-routes
                    |  +--rw address-allocation-type?
              |     |  |  |       identityref
              |     | address-family* [af]
                    |     +--rw provider-dhcp
              | af
                    |     |       vpn-common:address-family
                    |     +--rw provider-address?
              |     |  |  |  |       inet:ipv6-address
              |     |  |  | maximum-routes?   uint32
                    +--rw prefix-length?
              |     |  |  |  |       uint8
              |     |  |  |  +--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
              |     |  |  +--rw dhcp-relay
              |     |  |  |  +--rw provider-address?
              |     |  |  |  |       inet:ipv6-address
              |     |  |  |  +--rw prefix-length?           uint8
              |     |  |  |  +--rw customer-dhcp-servers
              |     |  |  |     +--rw server-ip-address*
              |     |  |  |             inet:ipv6-address
              |     |  |  +--rw static-addresses
              |     |  |     +--rw primary-address?   leafref
              |     |  |     +--rw address* [address-id]
              |     |  |        +--rw address-id          string
              |     |  |        +--rw provider-address?
              |     |  |        |       inet:ipv6-address
              |     |  |        +--rw customer-address?
              |     |  |        |       inet:ipv6-address
              |     |  |        +--rw prefix-length?      uint8
              |     |  +--rw oam
              |     |     +--rw bfd {l3vpn-svc:bfd}?
              |     |        +--rw enabled?              boolean
              |     |        +--rw (holdtime)?
              |     |           +--:(fixed)
              |     |           |  +--rw fixed-value?    uint32
              |     |           +--:(profile)
              |     |              +--rw profile-name?   leafref
              |     +--rw security
              |     |  ...
              |     +--rw routing-protocols
              |     |  ...
              |     +--rw service
              | multicast {vpn-common:multicast}?
                       ...

                   Figure 12: IP Connection Tree 9: VPN Node Subtree Structure

6.3.2.3.3.  Security

   The 'security' container specifies

7.3.4.1.  RT/RD Assignment/auto-assignment

   For the authentication and cases the
   encryption logical resources are managed outside the network
   controller, the model allows to be applied for a given VPN network access (Figure 13).

   module: ietf-l3vpn-ntw
     +--rw l3vpn-ntw
      +--rw vpn-profiles
      |  ...
      +--rw vpn-services
       +--rw vpn-service* [vpn-id]
          +--rw vpn-id                  l3vpn-svc:svc-id
          +  ...
          +--rw vpn-node* [ne-id]
              +--rw ne-id                      string
              + ...
              +--rw vpn-network-accesses
              |  +--rw vpn-network-access* [id]
              |     +--rw id
              |     |       l3vpn-svc:svc-id
              |     +  ...
              |     +--rw connection
              |     |  ...
              |     +--rw ip-connection
              |     |  ...
              |     +--rw security
              |     |  +--rw authentication
              |     |  +--rw encryption {l3vpn-svc:encryption}?
              |     |  |  +--rw enabled?   boolean
              |     |  |  +--rw layer?     enumeration
              |     |  +--rw encryption-profile
              |     |     +--rw (profile)?
              |     |     |  +--:(provider-profile)
              |     |     |  |  +--rw profile-name?    leafref
              |     |     |  +--:(customer-profile)
              |     |     |     +--rw algorithm?       string
              |     |     +--rw (key-type)?
              |     |        +--:(psk)
              |     |           +--rw preshared-key?   string
              |     +--rw routing-protocols
              |     |  ...
              |     +--rw service
              |        ...
              |  ...

                    Figure 13: Security Tree Structure

6.3.2.3.4.  CE PE Routing Protocols

   The model allows explicitely indicate the Provider logical
   resources such as Route targets (RTs) and Route Distinguishers (RDs)
   (RT,RD).

   Three possible behaviors are needed to configure one or more routing
   protocols associated with a particular 'vpn-network-access'
   (Figure 14). fulfil the identified use
   cases:

   o  The network controller auto-assigns logical resources (RTs, RDs).
      This protocol will run between can apply for new services deployment.

   o  The Network Operator/Service orchestrator assigns explicitly the PE
      RTs and the CE.  A
   routing protocol instance MUST have RDs.  This case will fit with a type (e.g., bgp, ospf) and an
   identifier.  The identifier is necessary when multiple instances of
   the same protocol have brownfield scenario where
      some existing services needs to be configured.

   When configuring multiple instances of updated by the same routing protocol, network
      operators.

   o  The Network Operator/Service orchestrator explicitly wants NO RT/
      RD to be assigned.  This case will fit in VRF-Lite scenarios, CE
      testing inside the Network or just for troubleshooting pruposes.

   Thus a union between two yang data types are included in order to
   support this does scenarios.  So, if the leaf is not automatically imply that, from created in the Yang
   the expected behavior is the auto-assigns.  If the Leaf is created
   with a device configuration
   perspective, there valid rd value it will be parallel instances (multiple processes)
   running.  It explicitly assign in the VPN Node
   and if the leaf is created with an empty value, the RD value will not
   be up to deployed in the implementation VPN node.

7.3.4.2.  VPN Network Access

   A 'vpn-network-access' represents an entry point to use a VPN service
   (Figure 10).  In other words, this container encloses the most
   appropriate deployment model. parameters
   that describe the access information for the traffic that belongs to
   a particular L3VPN.  As an example, when multiple BGP peers
   need such, every 'vpn-network-access' MUST belong
   to be implemented, multiple instances of BGP must be configured one and only one 'vpn-node'.

   A 'vpn-network-access' includes information such as part the connection on
   which the access is defined (see Section 7.3.4.2.1), the
   encapsulation of this model.  However, from the traffic, policies that are applied on the
   access, etc.

   Each 'vpn-network-access' SHOULD have a device configuration point 'vpn-network-access-type' to
   select the type of
   view, this could network interface to be implemented as:

   o  Multiple BGP processes with a single neighbor running deployed in each
      process. the devices.
   The available options are:

   o  A single BGP process with multiple neighbors running.

   o  A combination of both.

   To be aligned with [RFC8299], this model supports  Point-to-Point: The point-to-point type represent a direct
      connection between the following
   protocols:

   o  VRRP: takes only end-points.  It implies the controller must
      keep the association between a list of address-family as parameter.  VRRP
      instance is expected to run logical or physical interface on
      the 'vpn-network-access' interface.

   o  RIP: takes only a list device with the 'id' of address-family as parameter.  RIP
      instance is expected to run on the 'vpn-network-access' interface. vpn-network-access.

   o  BGP: allows to configure a BGP neighbor including parameters like
      authentication using  Multipoint: This option represents a key.  The authentication type will be
      driven by broadcast connection between
      two end-points.  It implies the implementation but controller must keep the module supports any
      authentication that uses a key as a parameter.  A BGP neighbor can
      support IPv4, IPv6, or both address families.  The module supports
      supplying two neighbors (each for
      association between a given address family) logical or one
      neighbor (for both IPv4 and IPv6 physical interface on the device
      with the 'id' of "address-family" attribute is
      set to both). the 'vpn-network-access'.

   o  Pseudowire: Represent a connection coming from an L2VPN service.
      It is then up to implies the implementation to drive controller must keep the
      device configuration.

   o  OSPF: allows relationship between the user to configure OSPF to run
      logical tunnels or bridges on the vpn-network-
      access interface.  An OSPF instance can run ipv4, ipv6 or both.
      When only ipv4 address-family is requested, it will be up to devices with the
      implementation to drive if OSPFv2 or v3 is used. 'id' of the'
      vpn-network-access'.

   o  IS-IS: allows  Loopback: It represents the user to configure IS-IS to run creation of a logical interface on the vpn-
      network-access interface.  An IS-IS instance can run L1, L2 or
      both levels.

   The module allows a user to configure one or more IPv4 and/or IPv6
   static routes.

   Routing configuration does not include low-level policies.  These
   policies are low level device configurations that must not be part of
   an abstracted model.
      devices.

   A provider's internal policies (such as
   security filters) PNC [RFC8453] will be implemented as part of the device
   configuration but does not require any input from accept VPN requests containing this model.  Some construct,
   using the enclosed data to: configure the router's interface to
   include the parameters described at the 'vpn-network-access', include
   the given interface into a VRF, configuring policies like primary/backup or load-balancing can be inferred from
   'access-priority'.

   module: ietf-l3vpn-ntw
     +--rw l3vpn-ntw
      +--rw vpn-profiles
      | schedulers
   for processing the incoming traffic, etc.

    ...
    +--rw vpn-services
       +--rw vpn-service* [vpn-id]
          +--rw vpn-id                  l3vpn-svc:svc-id                  vpn-common:vpn-id
          +  ...
           +--rw vpn-nodes
           +--rw vpn-node* [ne-id]
              +--rw ne-id                      string
              + ...
              +--rw status
              |  +--rw admin-enabled?   boolean
              |  +--ro oper-status?     operational-type
              +--rw vpn-network-accesses
              |  +--rw vpn-network-access* [id]
              |     +--rw id
              |     |       l3vpn-svc:svc-id
              |     +  ...
              |     +--rw connection
              |     |  ...
              |     +--rw ip-connection
              |     |  ...
              |     |  +--rw oam
              |     |     ...
              |     +--rw security
              |     |  ...       vpn-common:vpn-id
              |     +--rw routing-protocols
              | port-id?
              |  +--rw routing-protocol* [id]     |       vpn-common:vpn-id
              |     +--rw id description?               string
              |     |     +--rw type?               identityref
              |     |     +--rw routing-profiles* [id]
              |     |     |  +--rw id      leafref
              |     |     |  +--rw type?   ie-type
              |     |     +--rw ospf {l3vpn-svc:rtg-ospf}?
              |     |     |  +--rw address-family*
              |     |     |  |       l3vpn-svc:address-family
              | status
              |     |  +--rw area-address
              |     |     |  |       yang:dotted-quad admin-enabled?   boolean
              |     |  +--ro oper-status?     operational-type
              |     +--rw metric?           uint16
              |     | vpn-network-access-type?   identityref
              |     +--rw mtu?              uint16 connection
              |     |  ...
              |     +--rw process-id?       uint16 ip-connection
              |     |  ...
              |     +--rw security
              |     |     |  |  +--rw auth-key?   string
              |     |     |  +--rw sham-links
              |     |     |          {rtg-ospf-sham-link}?
              |     |     |     +--rw sham-link* [target-site]
              |     |     |        +--rw target-site
              |     |     |        |       l3vpn-svc:svc-id
              |     |     |        +--rw metric?        uint16
              |  ...
              |     +--rw bgp {l3vpn-svc:rtg-bgp}? routing-protocols
              |     |  ...
              |     +--rw peer-autonomous-system
              |     |     |  |       inet:as-number
              |     | service
              |        ...
              ...

               Figure 10: VPN Network Access Tree Structure

7.3.4.2.1.  Connection

   The definition of a L3VPN is commonly specified not only at the IP
   layer, but also requires to identify parameters at the Ethernet
   layer, such as encapsulation type (e.g., VLAN, QinQ, QinAny, VxLAN,
   etc.).  The 'connection' container represents and groups the set of
   Layer 2 connectivity from where the traffic of the L3VPN in a
   particular VPN Network access is coming.

   Ethernet encapsulation description is not supported in [RFC8299].
   However, this parameters are mandatory to configure the PE
   interfaces.  Thus, in the L3NM, these parameters uses the connection
   container inside the 'vpn-network-access'.  This container defines
   protocols and parameters to enable connectivity at Layer 2.

    ...
    +--rw local-autonomous-system?
              |     |     |  |       inet:as-number
              |     |     | vpn-services
       +--rw address-family*
              |     |     |  |       l3vpn-svc:address-family
              |     |     | vpn-service* [vpn-id]
          +--rw neighbor*
              | vpn-id                  vpn-common:vpn-id
          +  ...
           +--rw vpn-node* [ne-id]
              +--rw ne-id                      string
              + ...
              +--rw vpn-network-accesses
              |  +--rw vpn-network-access* [id]
              |     +--rw id
              |       inet:ip-address     |       vpn-common:vpn-id
              |     ...
              |     +--rw multihop?
              |     |     | connection
              |       uint8     |  +--rw encapsulation-type?   identityref
              |     |  +--rw security
              | logical-interface
              |     |  |  +--rw auth-key?   string
              | peer-reference?   uint32
              |     |  +--rw status
              | tagged-interface
              |     |  |  +--rw admin-enabled?   boolean type?                identityref
              |     |  |  +--rw dot1q-vlan-tagged
              |  +--ro oper-status?     |  |  |       {vpn-common:dot1q}?
              |          operational-type     |  |  |  +--rw description?
              | tag-type?   identityref
              |     |          string  |  |  +--rw isis {rtg-isis}? cvlan-id?   uint16
              |     |  |  +--rw address-family* priority-tagged
              |     |  |  |       l3vpn-svc:address-family  +--rw tag-type?   identityref
              |     |  |  +--rw area-address      area-address qinq {vpn-common:qinq}?
              |     |  |  |  +--rw level?            isis-level tag-type?   identityref
              |     |  |  |  +--rw metric? svlan-id    uint16
              |     |  |  |  +--rw process-id? cvlan-id    uint16
              |     |  |  +--rw mode?             enumeration
              |     | qinany {vpn-common:qinany}?
              |  +--rw status     |  |  |  +--rw admin-enabled?   boolean
              | tag-type?   identityref
              |     |     +--ro oper-status?  |  |  +--rw svlan-id    uint16
              |             operational-type     |  |  +--rw static vxlan {vpn-common:vxlan}?
              |     |  |     +--rw cascaded-lan-prefixes vni-id       uint32
              |     |  |     +--rw ipv4-lan-prefixes*
              |     | peer-mode?   identityref
              |     |       [lan next-hop]  |     +--rw peer-list* [peer-ip]
              |     |  |       {l3vpn-svc:ipv4}?        +--rw peer-ip    inet:ip-address
              |     |  +--rw bearer
              |     |     ...
              ...

                Figure 11: Encapsulation Subtree Structure

   Additionally, the 'bearer-reference' and the pseudowire termination
   are supported (see Figure 12).  A site, as per [RFC4176] represents 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.  The
   connection from the site to the Service Provider network is the
   bearer.  Every site is associated with a list of bearers.  A bearer
   is the layer two connections with the site.  In the module it is
   assumed that the bearer has been allocated by the Service Provider at
   the service orchestration step.  The bearer is associated to a
   network element and a port.  Hence, a bearer is just a bearer-
   reference to allow the translation between L3SM and L3NM.

   ...
   +--rw lan
              |     |     |     |  |       inet:ipv4-prefix
              |     |     | vpn-network-accesses
   |  +--rw lan-tag?    string
              |     |     | vpn-network-access* [id]
   |     +--rw next-hop
              |     |     | id
   |          inet:ipv4-address     |       vpn-common:vpn-id
   |     ...
   |     +--rw ipv6-lan-prefixes*
              |     |     |             [lan next-hop]
              |     |     |             {l3vpn-svc:ipv6}?
              |     | vpn-network-access-type?   identityref
   |     +--rw lan
              |     |     | connection
   |       inet:ipv6-prefix     |  ...
   |     |  +--rw lan-tag?    string
              | bearer
   |     |     +--rw next-hop bearer-reference?   string
   |     |     |                inet:ipv6-address       {vpn-common:bearer-reference}?
   |     |     +--rw rip {l3vpn-svc:rtg-rip}? pseudowire
   |     |     |  +--rw address-family* vcid?      uint32
   |     |     |          l3vpn-svc:address-family  +--rw far-end?   union
   |     |     +--rw vrrp {l3vpn-svc:rtg-vrrp}? vpls
   |     |        +--rw address-family*
              | vcid?      union
   |                l3vpn-svc:address-family     |        +--rw service far-end?   union
   |  ...

                    Figure 14: Routing Tree 12: Bearer Subtree Structure

6.3.2.3.5.  Services

7.3.4.2.2.  IP Connections

   IP connection container (Figure 13) has the parameters of the 'vpn-
   network-access' addressing information.  The 'services' address allocated in
   this container specifies would represent the service parameter to apply for
   a give VPN network access (Figure 15). PE interface address
   configuration.  The following attributes are
   defined:

   o  TBC

   module: ietf-l3vpn-ntw
     +--rw l3vpn-ntw
      +--rw vpn-profiles
      |  ...
      +--rw vpn-services
       +--rw vpn-service* [vpn-id]
          +--rw vpn-id                  l3vpn-svc:svc-id
          +  ...
          +--rw vpn-node* [ne-id]
              +--rw ne-id                      string
              + IP connection container is designed to support
   both IPv4 and IPv6.  It also supports three IP address assignment
   modes: SLAAC [RFC7527], Provider DHCP, DHCP relay, and static
   addressing.  Only one of them is enabled for a given service.

      ...
      +--rw vpn-network-accesses
      |  +--rw vpn-network-access* [id]
      |     +--rw id
      |     |       l3vpn-svc:svc-id       vpn-common:vpn-id
      |     +     ...
      |     +--rw vpn-network-access-type?   identityref
      |     +--rw connection
      |     |  ...

      |     +--rw ip-connection
      |     |  ...  +--rw ipv4 {vpn-common:ipv4}?
      |     |  |  +--rw security address-allocation-type?
      |     |  |  |       identityref
      |     |  ...  |  +--rw routing-protocols (allocation-type)?
      |     |  |     +--:(provider-dhcp)
      |     |  |  ...     |  +--rw service provider-address?
      |     |  |     |  |       inet:ipv4-address
      |     |  |     |  +--rw svc-input-bandwidth     uint64 prefix-length?
      |     |  |     |  |       uint8
      |     |  |     |  +--rw svc-output-bandwidth    uint64 (address-assign)?
      |     |  |     |     +--:(number)
      |     |  |     |     |  +--rw svc-mtu number-of-dynamic-address?
      |     |  |     |     |          uint16
      |        +--rw qos {l3vpn-svc:qos}?     |  |     |     +--:(explicit)
      |     |  |     |        +--rw qos-classification-policy customer-addresses
      |     |  |     |           +--rw rule* [id] address-group*
      |     |  |     |                   [group-id]
      |     |  |     |              +--rw id group-id
      |     |  |     |              |       string
      |     |  |     |              +--rw (match-type)? start-address?
      |     |  |     |  +--:(match-flow)              |       inet:ipv4-address
      |     |  |     |              +--rw (l3)?
              | end-address?
      |     |  |     |                      inet:ipv4-address
      |  +--:(ipv4)     |  |     +--:(dhcp-relay)
      |     |  |     |  +--rw dr-provider-address?
      |  ...     |  |     |  |       inet:ipv4-address
      |     |  +--:(ipv6)  |     |  +--rw dr-prefix-length?
      |     |  |     |     ...  |       uint8
      |     |  |     |  +--rw (l4)? customer-dhcp-servers
      |     |  |     |     +--rw server-ip-address*
      |     |  |     +--:(tcp)     |             inet:ipv4-address
      |     |  |     +--:(static-addresses)
      |     |  |        ...
      |     |  +--rw ipv6 {vpn-common:ipv6}?
      |     |  |     +--:(udp)  +--rw address-allocation-type?
      |     |  |  |       identityref
      |           ...     |  |  +--rw (allocation-type)?
      |     |  +--:(match-application)  |     +--:(provider-dhcp)
      |     |  |     |  +--rw match-application? (provider-dhcp)?
      |     |  |     |             identityref     +--:(provider-address)
      |     |  |     |     |  +--rw target-class-id? provider-address?
      |     |  |             string     |     |  +--rw qos-profile          inet:ipv6-address
      |     |     +--rw (qos-profile)?  |     |        +--:(standard)     +--:(prefix-length)
      |     |  |     |     |  +--rw profile?     leafref prefix-length?
      |     |  |  +--rw direction?   identityref     |     |        +--:(custom)          uint8
      |     |           ...  |        +--rw carrierscarrier     |     +--:(address-assign)
      |       {l3vpn-svc:carrierscarrier}?     |  |  +--rw signalling-type?   enumeration     |        +--rw multicast {l3vpn-svc:multicast}? (address-assign)?
      |     |  |     |           +--:(number)
      |     |  |     |           |  +--rw site-type?        enumeration number-of-dynamic-address?
      |     |  |     |           |          uint16
      |     |  |     |           +--:(explicit)
      |     |  |     |              +--rw address-family customer-addresses
      |     |  |     |                 +--rw ipv4?   boolean address-group*
      |     |  |       {l3vpn-svc:ipv4}?     |                         [group-id]
      |  +--rw ipv6?   boolean     |  |          {l3vpn-svc:ipv6}?     |                    +--rw protocol-type?    enumeration group-id
      |     |  |     |                    |       string
      |     |  |     |                    +--rw remote-source?    boolean start-address?
      |  ...

                    Figure 15: Services Tree Structure

6.3.2.4.  Multicast

   Multicast MAY be enabled for a particular vpn-network-node (see     |  |     |                    |       inet:ipv6-address
      |     |  |     |                    +--rw end-address?
      |     |  |     |                            inet:ipv6-address
      |     |  |     +--:(dhcp-relay)
      |     |  |     |  +--rw dr-provider-address?
      |     |  |     |  |       inet:ipv6-address
      |     |  |     |  +--rw dr-prefix-length?
      |     |  |     |  |       uint8
      |     |  |     |  +--rw customer-dhcp-servers
      |     |  |     |     +--rw server-ip-address*
      |     |  |     |             inet:ipv6-address
      |     |  |     +--:(static-addresses)
      |     |  |        ...

                Figure 16).

   The model supports a single type 13: IP Connection Subtree Structure

   In the case of tree (Any-Source Multicast (ASM),
   Source-Specific Multicast (SSM), or bidirectional).

   When ASM is used, the static addressing (Figure 14), 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 assignment of several IP addresses in the 'rp-group-mappings' container.  The RP MAY
   be a provider node or a customer node.  When same 'vpn-network-
   access'.  To identify which of the RP addresses is a customer
   node, the RP address must be configured using the 'rp-address' leaf
   otherwise no RP primary 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 connection ,the 'primary-address' reference MUST be set.  When set to 'true',
   the implementation must use any mechanism to provide a more optimal
   traffic delivery for the customer.  Anycast is one of with the mechanisms
   to enhance RPs redundancy, resilience against failures, and to
   recover from failures quickly.

   For redundancy purposes, Multicast Source Discovery Protocol (MSDP)
   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.

   module: ietf-l3vpn-ntw
     +--rw l3vpn-ntw
      +--rw vpn-profiles
      |  ...
       +--rw vpn-service* [vpn-id]
          +--rw vpn-id                  l3vpn-svc:svc-id
          + ..
          +--rw vpn-nodes
           +--rw vpn-node* [ne-id]
              +--rw ne-id                      string
              +
   corresponding 'address-id'.

              ...
              +--rw vpn-network-accesses
                 |  ...  +--rw multicast {l3vpn-svc:multicast}? vpn-network-access* [id]
                 |     +--rw enabled?       boolean id
                 |     |       vpn-common:vpn-id
                 |     ...
                 |     +--rw tree-flavor* vpn-network-access-type?   identityref
                 |     +--rw rp connection
                 |     |  +--rw rp-group-mappings  ...
                 |     +--rw ip-connection
                 |     |  +--rw rp-group-mapping* [id] ipv4 {vpn-common:ipv4}?
                 |     |  |  +--rw id                  uint16 address-allocation-type?
                 |     |  |     +--rw provider-managed  |       identityref
                 |     |  |  +--rw enabled? (allocation-type)?
                 |     |  |     ...
                 |     |       boolean  |     +--:(static-addresses)
                 |     |  |        +--rw rp-redundancy?
              |  | primary-address?
                 |     |  |       boolean        |       -> ../address/address-id
                 |     |  |        +--rw optimal-traffic-delivery? address* [address-id]
                 |     |  |           +--rw address-id
                 |     |  |       boolean           |       string
                 |     |  |           +--rw anycast s-provider-address?
                 |     |  |           |     +--rw local-address?       inet:ipv4-address
                 |     |  |           +--rw s-customer-address?
                 |     |       inet:ip-address  |           |       inet:ipv4-address
                 |     |  |           +--rw rp-set-address* s-prefix-length?
                 |     |  |                   uint8
                 |     |             inet:ip-address  +--rw ipv6 {vpn-common:ipv6}?
                 |     |  |  +--rw rp-address address-allocation-type?
                 |     |  |  |       inet:ip-address       identityref
                 |     |  |  +--rw groups (allocation-type)?
                 |     |  |        +--rw group* [id]     ...
                 |     |  |     +--:(static-addresses)
                 |     |  |        +--rw id s-primary-address?
                 |     |  |        |       uint16       -> ../s-address/address-id
                 |     |  |        +--rw (group-format) s-address* [address-id]
                 |     |  |              +--:(group-prefix)           +--rw address-id
                 |     |  |           |  +--rw group-address?       string
                 |     |  |           +--rw provider-address?
                 |          inet:ip-prefix     |  |           |              +--:(startend)       inet:ipv6-address
                 |     |  |           +--rw group-start? customer-address?
                 |     |  |           |       inet:ip-address       inet:ipv6-address
                 |     |  |           +--rw group-end? prefix-length?      uint8
                 ...

          Figure 14: IP Connection Subtree Structure: Static Mode

7.3.4.2.3.  Security

   The 'security' container specifies the authentication and the
   encryption to be applied for a given VPN network access (Figure 15).

              ...
              +--rw vpn-network-accesses
              |  +--rw vpn-network-access* [id]
              |     +--rw id
              |                         inet:ip-address     |       vpn-common:vpn-id
              |     +  ...
              |     +--rw rp-discovery connection
              |     |  ...
              |     +--rw rp-discovery-type?   identityref ip-connection
              |     |  ...
              |     +--rw bsr-candidates security
              |     |  +--rw bsr-candidate-address*
              | encryption {vpn-common:encryption}?
              |                inet:ip-address     |  +--rw msdp {msdp}?  |  +--rw enabled?   boolean
              |     |  |  +--rw peer?            inet:ip-address layer?     enumeration
              |     |  +--rw local-address?   inet:ip-address
              + ...

                    Figure 16: Multicast Tree Structure

6.3.3.  Concept of Import/Export Profiles

   The import and export profiles construct contains a list with
   information related with route target and distinguishers (RTs and
   RDs), grouped and identified by ie-profile-id.  The identifier is
   then referenced in one or multiple vpn-nodes, so the PNC can identify
   RTs and RDs to be configured in the VRF.

6.3.4.  Underlay Transport

   The model allows to indicate a preference for the underlay transport
   technology when activating a L3VPN service.  This preference is
   especially useful in networks with multiple domains and NNI types.
   The model supports these option: BGP, LDP, GRE, SR, SR-TE, and RSVP-
   TE as possible underlay transport.

   Other profiles can be defined in the future.

   This document does not make any assumption about the exact definition
   of these profiles.  How such profiles are defined is deployment-
   specific.

7.  L3NM Module Tree Structure

   The L3NM Module Tree Structure is depicted in Figure 17.

module: ietf-l3vpn-ntw
  +--rw l3vpn-ntw
   +--rw vpn-profiles
   |  +--rw valid-provider-identifiers
   |     +--rw cloud-identifier* [id] {l3vpn-svc:cloud-access}?
   |     |  +--rw id    string
   |     +--rw encryption-profile-identifier* [id]
   |     |  +--rw id    string
   |     +--rw qos-profile-identifier* [id]
   | encryption-profile
              |  +--rw id    string     |     +--rw bfd-profile-identifier* [id] (profile)?
              |     |  +--rw id    string     |     +--rw routing-profile-identifier* [id]  +--:(provider-profile)
              |        +--rw id    string
   +--rw vpn-services
    +--rw vpn-service* [vpn-id]
       +--rw service-status     |  +--rw admin     |  |  +--rw status?      operational-type
       | profile-name?    leafref
              |  +--rw timestamp?   yang:date-and-time     |  +--ro ops     |     +--ro status?      operational-type  +--:(customer-profile)
              |     +--ro timestamp?   yang:date-and-time
       +--rw vpn-id                  l3vpn-svc:svc-id
       +--rw l3sm-vpn-id?            l3vpn-svc:svc-id
       +--rw customer-name?          string
       +--rw vpn-service-topology?   identityref
       +--rw description?            string
       +--rw ie-profiles     |  +--rw ie-profile* [ie-profile-id]     |     +--rw ie-profile-id algorithm?       string
              |     +--rw rd?              rt-types:route-distinguisher
       |     +--rw vpn-targets     |     +--rw vpn-target* [id] (key-type)?
              |     |  +--rw id                   int8        +--:(psk)
              |     |           +--rw route-targets* [route-target]
       |        | preshared-key?   string
              |     +--rw route-target
       |        | routing-protocols
              |          rt-types:route-target     |  ...
              |     +--rw route-target-type
       | service
              |          rt-types:route-target-type        ...
              |  ...

                   Figure 15: Security Subtree Structure

7.3.4.2.4.  CE-PE Routing Protocols

   The model allows the Provider to configure one or more routing
   protocols associated with a particular 'vpn-network-access'
   (Figure 16).  This protocol will run between the PE and the CE.  A
   routing protocol instance MUST have a type (e.g., bgp, ospf) and an
   identifier.  The identifier is necessary when multiple instances of
   the same protocol have to be configured.

                    ...
                    +--rw vpn-policies
       |           +--rw import-policy?   leafref
       |           +--rw export-policy?   leafref
       +--rw underlay-transport
       |  +--rw type*   protocol-type
       +--rw vpn-nodes
        +--rw vpn-node* [ne-id]
           +--rw vpn-node-id?               union
           +--rw local-autonomous-system?   inet:as-number
           +--rw description?               string
           +--rw ne-id                      string
           +--rw router-id?                 inet:ip-address
           +--rw address-family?
           |       l3vpn-svc:address-family
           +--rw node-role?                 identityref
           +--rw rd?                        union
           +--rw vpn-targets vpn-network-accesses
                    |  +--rw vpn-target* vpn-network-access* [id]
                    |  |     +--rw id                   int8
           |  |  +--rw route-targets* [route-target]
           |  |  |  +--rw route-target
                    |     |       vpn-common:vpn-id
                    |          rt-types:route-target
           |  |  +--rw route-target-type
           |  |          rt-types:route-target-type     ...
                    |     +--rw vpn-policies ip-connection
                    |     +--rw import-policy?   leafref     |     +--rw export-policy?   leafref
           +--rw status  ...
                    |     +--rw admin-enabled?   boolean routing-protocols
                    |  +--ro oper-status?     operational-type
           +--rw vpn-network-accesses     |  +--rw vpn-network-access* routing-protocol* [id]
                    |     +--rw id
           |     |       l3vpn-svc:svc-id
           |     +--rw port-id?
           |     |       l3vpn-svc:svc-id     |     +--rw description? id                  string
                    |     +--rw status
           |     |  +--rw admin-enabled?   boolean
           |     |  +--ro oper-status?     operational-type
           |     +--rw vpn-network-access-type?   identityref
           |     +--rw connection
           |     |     +--rw encapsulation-type? type?               identityref
                    |     |     +--rw logical-interface
           |     | routing-profiles* [id]
                    |  +--rw peer-reference?   uint32     |     |  +--rw tagged-interface id      leafref
                    |     |     |  +--rw type?   identityref
                    |     |  |     +--rw dot1q-vlan-tagged {dot1q}?
           |     |  | ospf {vpn-common:rtg-ospf}?
                    |  +--rw tag-type?   identityref     |     |  ...
                    |     |     +--rw cvlan-id?   uint16
           |     | bgp {vpn-common:rtg-bgp}?
                    |  +--rw priority-tagged     |     |  ...
                    |     |     +--rw tag-type?   identityref
           |     | isis {vpn-common:rtg-isis}?
                    |  +--rw qinq {qinq}?     |     |  ...
                    |     |     +--rw tag-type?   identityref
           |     |  | static
                    |  +--rw svlan-id    uint16     |     |  ...
                    |     |     +--rw cvlan-id    uint16 rip {vpn-common:rtg-rip}?
                    |     |     |  +--rw qinany {qinany}?
           |     |  | address-family*
                    |  +--rw tag-type?   identityref     |     |          vpn-common:address-family
                    |     |     +--rw svlan-id    uint16
           | vrrp {vpn-common:rtg-vrrp}?
                    |     |        +--rw vxlan {vxlan}? address-family*
                    |     |                vpn-common:address-family
                    |     +--rw vni-id       uint32 service
                    |        ...
                    ...

                   Figure 16: Routing Subtree Structure

   Routing configuration does not include low-level policies.  These
   policies are low level device configurations that must not be part of
   an abstracted model.  A provider's internal policies (such as
   security filters) will be implemented as part of the device
   configuration but does not require any input from this model.  Some
   policies like primary/backup or load-balancing can be inferred from
   'access-priority'.

   When configuring multiple instances of the same routing protocol,
   this does not automatically imply that, from a device configuration
   perspective, there will be parallel instances (multiple processes)
   running.  It will be up to the implementation to use the most
   appropriate deployment model.  As an example, when multiple BGP peers
   need 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 of both.

   To be aligned with [RFC8299], this model supports the following CE-PE
   routing protocols:

   o  OSPF: The model (Figure 17) allows the user to configure OSPF to
      run as routing protocol on the 'vpn-network-access interface'.  An
      OSPF instance can be bound to IPv4, IPv6 or both.  When only IPv4
      address-family is requested, it will be up to the implementation
      to drive whether OSPFv2 or OSPFv3 is used.

                 ...
                 +--rw vpn-network-accesses
                 |  +--rw vpn-network-access* [id]
                 |     +--rw peer-mode?   identityref id
                 |     |       vpn-common:vpn-id
                 |     ...
                 |     +--rw peer-list* [peer-ip] ip-connection
                 |     |  ...
                 |     +--rw peer-ip    inet:ip-address routing-protocols
                 |     |  +--rw bearer routing-protocol* [id]
                 |     |     +--rw bearer-reference? id                  string
                 |     |     |       {l3vpn-svc:bearer-reference}?
           |     |     +--rw pseudowire
           |     |     |  +--rw vcid?      uint32
           |     |     |  +--rw far-end?   union
           |     |     +--rw vpls
           |     |     +--rw vcid?      union type?               identityref
                 |     |     +--rw far-end?   union routing-profiles* [id]
                 |     +--rw ip-connection     |     |  +--rw ipv4 {l3vpn-svc:ipv4}? id      leafref
                 |     |     |  +--rw address-allocation-type?
           |     |  |  | type?   identityref
                 |     |  |     +--rw provider-dhcp
           | ospf {vpn-common:rtg-ospf}?
                 |     |     |  +--rw provider-address?
           |     | address-family*
                 |     |     |       inet:ipv4-address  |       vpn-common:address-family
                 |     |     |  +--rw prefix-length?
           |     | area-address
                 |     |     |       uint8  |       yang:dotted-quad
                 |     |     |  +--rw (address-assign)?
           |     |  |  |     +--:(number)
           |     | metric?           uint16
                 |     |     |  +--rw number-of-dynamic-address?
           |     |  |  |     | mtu?              uint16
                 |     |     |  |     +--:(explicit)
           |     |  |  |  +--rw customer-addresses
           | process-id?       uint16
                 |     |     |  +--rw address-group*
           |     |  |  |                   [group-id] security
                 |     |     |  |  +--rw group-id
           |     |  |  |              | auth-key?   string
                 |     |     |  |              +--rw start-address?
           |     |  |  |              |       inet:ipv4-address
           |     |  |  |              +--rw end-address?
           |     |  |  |                      inet:ipv4-address
           |     |  |  +--rw dhcp-relay
           |     |  |  |  +--rw provider-address?
           |     |  |  |  |       inet:ipv4-address
           |     |  |  |  +--rw prefix-length?           uint8
           |     |  |  |  +--rw customer-dhcp-servers
           |     |  |  |     +--rw server-ip-address*
           |     |  |  |             inet:ipv4-address
           |     |  |  +--rw static-addresses
           |     |  |     +--rw primary-address?   leafref
           |     |  |  +--rw address* [address-id] sham-links
                 |     |     |        +--rw address-id          string          {vpn-common:rtg-ospf-sham-link}?
                 |     |     |     +--rw provider-address?
           |     |  |        |       inet:ipv4-address sham-link* [target-site]
                 |     |     |        +--rw customer-address?
           |     | target-site
                 |     |       inet:ipv4-address     |        |       vpn-common:vpn-id
                 |        +--rw prefix-length?      uint8     |     |        +--rw ipv6 {l3vpn-svc:ipv6}?
           | metric?        uint16
                 |     |     +--rw address-allocation-type?
           |     |  |  |       identityref
           |     | bgp {vpn-common:rtg-bgp}?
                 |  +--rw provider-dhcp     |     |  ...
                 |     |     +--rw provider-address?
           |     |  |  | isis {vpn-common:rtg-isis}?
                 |       inet:ipv6-address     |     |  ...
                 |     |     +--rw prefix-length?
           |     |  |  | static
                 |       uint8     |     |  ...
                 |     |     +--rw (address-assign)?
           |     |  |  |     +--:(number) rip {vpn-common:rtg-rip}?
                 |     |     |  ...
                 |     |     +--rw number-of-dynamic-address?
           |     |  |  |     |          uint16
           |     |  |  |     +--:(explicit)
           | vrrp {vpn-common:rtg-vrrp}?
                 |     |        ...
                 |     +--rw customer-addresses
           |     |  | service
                 |           +--rw address-group*
           |     |  |  |                   [group-id]
           |     |  |  |              +--rw group-id
           |     |  |  |              |       string
           |     |  |  |              +--rw start-address?
           |     |  |  |              |       inet:ipv6-address
           |     |  |  |              +--rw end-address?
           |     |  |  |                      inet:ipv6-address
           |     |  |  +--rw dhcp-relay
           |     |  |  |  +--rw provider-address?
           |     |  |  |  |       inet:ipv6-address
           |     |  |  |  +--rw prefix-length?           uint8
           |     |  |  |  +--rw customer-dhcp-servers
           |     |  |  |     +--rw server-ip-address*
           |     |  |  |             inet:ipv6-address
           |     |  |  +--rw static-addresses
           |     |  |     +--rw primary-address?   leafref
           |     |  |     +--rw address* [address-id]
           |     |  |        +--rw address-id          string
           |     |  |        +--rw provider-address?
           |     |  |        |       inet:ipv6-address
           |     |  |        +--rw customer-address?
           |     |  |        |       inet:ipv6-address
           |     |  |        +--rw prefix-length?      uint8
           |     |  +--rw oam
           |     |     +--rw bfd {l3vpn-svc:bfd}?
           |     |        +--rw enabled?              boolean
           |     |        +--rw (holdtime)?
           |     |           +--:(fixed)
           |     |           |  +--rw fixed-value?    uint32
           |     |           +--:(profile)
           |     |              +--rw profile-name?   leafref
           |     +--rw security
           |     |  +--rw authentication
           |     |  +--rw encryption {l3vpn-svc:encryption}?
           |     |  |  +--rw enabled?   boolean
           |     |  |  +--rw layer?     enumeration
           |     |  +--rw encryption-profile
           |     |     +--rw (profile)?
           |     |     |  +--:(provider-profile)
           |     |     |  |  +--rw profile-name?    leafref
           |     |     |  +--:(customer-profile)
           |     |     |     +--rw algorithm?       string
           |     |     +--rw (key-type)?
           |     |        +--:(psk)
           |     |           +--rw preshared-key?   string
           |     +--rw routing-protocols
           |     |  +--rw routing-protocol* [id]
           |     |     +--rw id                  string
           |     |     +--rw type?               identityref
           |     |     +--rw routing-profiles* [id]
           |     |     |  +--rw id      leafref
           |     |     |  +--rw type?   ie-type
           |     |     +--rw ospf {l3vpn-svc:rtg-ospf}?
           |     |     |  +--rw address-family*
           |     |     |  |       l3vpn-svc:address-family
           |     |     |  +--rw area-address
           |     |     |  |       yang:dotted-quad
           |     |     |  +--rw metric?           uint16
           |     |     |  +--rw mtu?              uint16
           |     |     |  +--rw process-id?       uint16
           |     |     |  +--rw security
           |     |     |  |  +--rw auth-key?   string
           |     |     |  +--rw sham-links
           |     |     |          {rtg-ospf-sham-link}?
           |     |     |     +--rw sham-link* [target-site]
           |     |     |        +--rw target-site
           |     |     |        |       l3vpn-svc:svc-id
           |     |     |        +--rw metric?        uint16
           |     |     +--rw bgp {l3vpn-svc:rtg-bgp}?
           |     |     |  +--rw peer-autonomous-system
           |     |     |  |       inet:as-number
           |     |     |  +--rw local-autonomous-system?
           |     |     |  |       inet:as-number
           |     |     |  +--rw address-family*
           |     |     |  |       l3vpn-svc:address-family
           |     |     |  +--rw neighbor*
           |     |     |  |       inet:ip-address
           |     |     |  +--rw multihop?
           |     |     |  |       uint8
           |     |     |  +--rw security
           |     |     |  |  +--rw auth-key?   string
           |     |     |  +--rw status
           |     |     |  |  +--rw admin-enabled?   boolean
           |     |     |  |  +--ro oper-status?
           |     |     |  |          operational-type
           |     |     |  +--rw description?
           |     |     |          string
           |     |     +--rw isis {rtg-isis}?
           |     |     |  +--rw address-family*
           |     |     |  |       l3vpn-svc:address-family
           |     |     |  +--rw area-address      area-address
           |     |     |  +--rw level?            isis-level
           |     |     |  +--rw metric?           uint16
           |     |     |  +--rw process-id?       uint16
           |     |     |  +--rw mode?             enumeration
           |     |     |  +--rw status
           |     |     |     +--rw admin-enabled?   boolean
           |     |     |     +--ro oper-status?
           |     |     |             operational-type
           |     |     +--rw static
           |     |     |  +--rw cascaded-lan-prefixes
           |     |     |     +--rw ipv4-lan-prefixes*
           |     |     |     |       [lan next-hop]
           |     |     |     |       {l3vpn-svc:ipv4}?
           |     |     |     |  +--rw lan
           |     |     |     |  |       inet:ipv4-prefix
           |     |     |     |  +--rw lan-tag?    string
           |     |     |     |  +--rw next-hop
           |     |     |     |          inet:ipv4-address
           |     |     |     +--rw ipv6-lan-prefixes*
           |     |     |             [lan next-hop]
           |     |     |             {l3vpn-svc:ipv6}?
           |     |     |        +--rw lan
           |     |     |        |       inet:ipv6-prefix
           |     |     |        +--rw lan-tag?    string
           |     |     |        +--rw next-hop
           |     |     |                inet:ipv6-address
           |     |     +--rw rip {l3vpn-svc:rtg-rip}?
           |     |     |  +--rw address-family*
           |     |     |          l3vpn-svc:address-family
           |     |     +--rw vrrp {l3vpn-svc:rtg-vrrp}?
           |     |        +--rw address-family*
           |     |                l3vpn-svc:address-family
           |     +--rw service
           |        +--rw svc-input-bandwidth     uint64
           |        +--rw svc-output-bandwidth    uint64
           |        +--rw svc-mtu                 uint16
           |        +--rw qos {l3vpn-svc: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 (dst-network)?
           |        |  |     |  |  |  |     | +--:(dst-ipv4-network)
           |        |  |     |  |  |  |     |  +--rw dst-ipv4-network?
           |        |  |     |  |  |  |     |    inet:ipv4-prefix
           |        |  |     |  |  |  |     +--rw (source-network)?
           |        |  |     |  |  |  |      +--:(src-ipv4-network)
           |        |  |     |  |  |  |        +--rw src-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)?
           |        |  |     |  |  |        |  +--:(dst-ipv6-network)
           |        |  |     |  |  |        |    +--rw dst-ipv6-network?
           |        |  |     |  |  |        |       inet:ipv6-prefix
           |        |  |     |  |  |        +--rw (src-network)?
           |        |  |     |  |  |        |  +--:(src-ipv6-network)
           |        |  |     |  |  |        |    +--rw src-ipv6-network?
           |        |  |     |  |  |        |       inet:ipv6-prefix
           |        |  |     |  |  |        +--rw flow-label?
           |        |  |     |  |  |                inet:ipv6-flow-label
           |        |  |     |  |  +--rw (l4)?
           |        |  |     |  |     +--:(tcp)
           |        |  |     |  |     |  +--rw tcp
           |        |  |     |  |     |     +--rw sequence-number?
           |        |  |     |  |     |     |       uint32
           |        |  |     |  |     |     +--rw ack-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)?
           |        |  |     |  |     |     |   ...
           |        |  |     |  |     |     +--rw (destination-port)?
           |        |  |     |  |     |     |  ...
           |        |  |     |  |     +--:(udp)
           |        |  |     |  |        +--rw udp
           |        |  |     |  |           +--rw length?
           |        |  |     |  |           |       uint16
           |        |  |     |  |           +--rw (source-port)?
           |        |  |     |  |           |  ...
           |        |  |     |  |           +--rw (destination-port)?
           |        |  |     |  |           |  ...
           |        |  |     |  +--:(match-application)
           |        |  |     |     +--rw match-application?
           |        |  |     |             identityref
           |        |  |     +--rw target-class-id?
           |        |  |             string
           |        |  +--rw qos-profile
           |        |     +--rw qos-profile* [profile]
           |        |        +--rw profile      -> /l3vpn-ntw/...
           |        |        +--rw direction?   identityref
           |        +--rw carrierscarrier
           |        |       {l3vpn-svc:carrierscarrier}?
           |        |  +--rw signalling-type?   enumeration
           |        +--rw multicast {l3vpn-svc:multicast}?
           |           +--rw site-type?        enumeration
           |           +--rw address-family
           |           |  +--rw ipv4?   boolean
           |           |  |       {l3vpn-svc:ipv4}?
           |           |  +--rw ipv6?   boolean
           |           |          {l3vpn-svc:ipv6}?
           |           +--rw protocol-type?    enumeration
           |           +--rw remote-source?    boolean
           +--rw maximum-routes
           |  +--rw address-family* [af]
           |     +--rw af
           |     |       l3vpn-svc:address-family
           |     +--rw maximum-routes?   uint32
           +--rw multicast {l3vpn-svc:multicast}?
           |  +--rw enabled?       boolean
           |  +--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 msdp {msdp}?
           |     +--rw enabled?         boolean
           |     +--rw peer?            inet:ip-address
           |     +--rw local-address?   inet:ip-address
           +--rw node-ie-profile?           leafref

                                 Figure 17

8.  Sample Uses of the L3NM Data Model

8.1.  Enterprise L3 VPN Services

   Enterprise L3VPNs are one of the most demanded services for carriers,
   and therefore, L3NM can be useful to automate the tasks of
   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 SDN layer and little manual intervention will be still
   required.

   Also common addition/removal of sites of an existing customer VPN can
   benefit of using L3NM, by creation of workflows that either prune or
   add nodes as required from the network data model object.

8.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 to avoid asymmetric (non-functional) configuration, or the
   usage of unavailable resources.

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

8.3.  Management of Multicast services

   Multicast services over L3VPN can be implemented either using dual
   PIM MVPNs (also known as Draft Rosen model) [RFC 4364] or
   multiprotocol BGP (MBGP)-based MVPNs called Next Generation Multicast
   VPN (ng-MVPN) [RFC 6513/6514].  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
   backbone.  Multiprotocol BGP multicast VPNs employ the intra-
   autonomous system (AS) next-generation BGP control plane and PIM
   sparse mode as the data plane.  The PIM state information is
   maintained between the PE routers using the same architecture that is
   used for unicast VPNs.

   On the other hand, Draft Rosen 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 this, ng-MNPN is the architectural model that
   has been taken as the base for implementing multicast service on
   L3VPN.  In this scenario, BGP auto discovery is used to discover MVPN
   PE members and the customer PIM signaling is sent across provider
   core through MP-BGP.  The multicast traffic is transported on MPLS
   P2MP LSPs.  All of the previous information is carried in the MCAST-
   VPN BGP NRLI.

9.  L3VPN Examples

9.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 18, 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 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.168.0.2      |  10.0.0.1        |
         |   eNodeB    |>--------/------->|...........       |
         |             |          Vlan 1  |          |       |
         |             |>--------/------->|......    |       |
         |             |          Vlan 2  |     |    |       |
         |             | Direct           |  +-------------+ |
         +-------------+ Routing          |  | vpn-node-id | |
                                          |  | 44          | |
                                          |  +-------------+ |
                                          |                  |
                                          +------------------+

                    Figure 18: Mobile Backhaul Example

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

   First: Create the 4G VPN Service (Figure 19).

   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"
       ]
     }
   }

                       Figure 19: Create VPN Service

   Second: Create a VPN Node as depicted in Figure 20.  In this type of
   service, the VPN Node is equivalent to the VRF configured in the
   physical device ('ne-id'=10.0.0.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": "10.0.0.1",
         "local-autonomous-system": "65550",
         "rd": "0:65550:1",
         "vpn-targets": {
           "vpn-target": [
             "id": "1",
             "route-targets": ["route-target": "0:65550:1"],
             "route-target-type": "both"
           }
         }
       ]
     }
   }

                        Figure 20: 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 21).

   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": "1/1/1.1",
           "port-id": "1/1/1",
           "description": "Interface SYNC to eNODE-B",
           "status": {"admin-enabled": "true"},
           "vpn-network-access-type": "l3vpn-svc:point-to-point",
           "ip-connection": {
             "ipv4": {
               "address-allocation-type": "l3vpn-svc:static-address",
               "static-addresses": {
                 "primary-address": "1",
                 "address": [
                   "address-id": "1",
                   "provider-address": "192.168.0.1",
                   "customer-address": "192.168.0.1",
                   "prefix-length": "32"
                 ]
               }
             }
           },
           "routing-protocols": {
             "routing-protocol": [
               "id": "1",
               "type": "l3vpn-svc:direct"
             ]
           }
         },
         {
           "vpn-network-access-id": "1/1/1.2",
           "port-id": "1/1/1",
           "description": "Interface DATA to eNODE-B",
           "status": {"admin-enabled": "true"},
           "ip-connection": {
             "ipv4": {
               "static-addresses": {
                 "primary-address": "1",
                 "address": [
                   "address-id": "1",
                   "provider-address": "192.168.1.1",
                   "customer-address": "192.168.1.2",
                   "prefix-length": "32"
                 ]
               }
             }
           },
           "routing-protocols": {
             "routing-protocol": [
               "id": "1",
               "type": "l3vpn-svc:direct"
             ]
           }
         }
       ]
     }
   }

                   Figure 21: Create VPN Network Access

9.2.  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 22: Multicast L3VPN Service Example

   To configure a Multicast L3VPN service using the L3NM model the
   procedure and the JSON with the data structure is the following:

   First, the multicast service is created (see the excerpt of the
   request message body shown in Figure 23)

                "vpn-services": {
                       "vpn-service": {
                         "vpn-id": "Multicast_IPTV",
                         "customer-name": "310",
                         "vpn-service-topology": "hub-spoke",
                         "description": "Multicast IPTV VPN service"
                       }
                   }

      Figure 23: 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 24).  In this example, the VPN Node will
   represent VRF configured in the physical device.

               "vpn-node": [
                 "vpn-node-id": "500003105",
                 "ne-id": "10.250.2.202",
                 "autonomous-system": "3816",
                 "description": "VRF_IPTV_MULTICAST",
                 "router-id": "10.250.2.202",
                 "address-family": "ipv4",
                 "node-role": {
                   "l3vpn-svc:hub-role"
                 },
                 "rd": "3816:31050202",
                 "multicast": {
                   "enabled": "true",
                   "rp": {
                     "rp-group-mappings": {
                       "rp-group-mapping": {
                         "id": "1",
                         "rp-address": "172.19.48.17",
                         "groups": {
                           "group": {
                             "id": "1",
                             "group-address": "239.130.0.0/15"
                           }
                         }
                       }
                     },
                     "rp-discovery": {
                       "rp-discovery-type": {
                         "l3vpn-svc:static-rp"
                       }
                     }
                   }
                 }
               ]

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

   Finally, create the VPN Network Access with Multicast enabled (see
   the excerpt of the request message body shown in Figure 25)

             "vpn-network-access": {
               "vpn-network-access-id": "1/1/1",
               "description": "Connected_to_source",
               "status": { "admin-enabled": "true" },
               "vpn-network-access-type": {
                 "l3vpn-svc:point-to-point"
               },
               "ip-connection": {
                 "ipv4": {
                   "address-allocation-type": {
                     "l3vpn-svc:static-address"
                   },
                   "static-addresses": {
                     "primary-address": "1",
                     "address": {
                       "address-id": "1",
                       "provider-address": "172.19.48.1",
                       "prefix-length": "30"
                     }
                   }
                 }
               },
               "routing-protocols": {
                 "routing-protocol": {
                   "id": "1",
                   "type": {
                     "l3vpn-svc:bgp"
                   },
                   "bgp": {
                     "peer-autonomous-system": "6500",
                     "local-autonomous-system": "3816",
                     "address-family": "ipv4",
                     "neighbor": "172.19.48.2",
                     "description": "Connected_to_CE"
                   }
                 }
               },
               "service": {
                 "multicast": {
                   "multicast-site-type": "source-only",
                   "multicast-address-family": { "ipv4": "true" },
                   "protocol-type": "router"
                 }
               }
             }

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

10.  L3NM YANG Module

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

  import ietf-inet-types {
    prefix inet;
    reference
      "Section 4 of RFC 6991";
  }
  import ietf-yang-types {
    prefix yang;
    reference
      "Section 3 of RFC 6991";
  }
  import ietf-netconf-acm {
    prefix nacm;
    reference
      "RFC 8341: Network Configuration Access Control Model";
  }
  import ietf-routing-types {
    prefix rt-types;
    reference
      "RFC 8294: Common YANG Data Types for the Routing Area";
  }
  import ietf-l3vpn-svc {
    prefix l3vpn-svc;
    reference
      "RFC 8299: YANG Data Model for L3VPN Service Delivery";
  }
  import ietf-packet-fields {
    prefix packet-fields;
    reference
      "RFC 8519: YANG Data Model for Network Access
                 Control Lists (ACLs)";
  }

  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>
        Author:   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) 2020 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
     (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 2020-04-03 {
    description
      "Initial revision.";
    reference
      "RFC XXXX: A Layer 3 VPN Network YANG Model";
      // RFC Ed.: replace XXXX with actual RFC number and remove
     // this note
  }

  /* Features */

  feature msdp {
    description
      "This feature indicates that msdp capabilities
       are supported by the VPN.";
  }

  feature rtg-isis {
    description
      "This features indicates the support of the ISIS
       routing protocol.";
  }

  feature rtg-ospf-sham-link {
    description
      "This feature indicates the support of OSPF sham links.";
  }
  feature input-bw {
    description
      "This feature indicates the support of
       the 'input-bw' limit.";
  }

  feature dot1q {
    description
      "This feature indicates the support of
       the 'dot1q' encapsulation.";
  }

  feature qinq {
    description
      "This feature indicates the support of
       the 'qinq' encapsulation.";
  }

  feature qinany {
    description
      "This feature indicates the support of
       the 'qinany' encapsulation.";
  }

  feature vxlan {
    description
      "This feature indicates the support of
       the 'vxlan' encapsulation.";
  }

  /* Typedefs */

  typedef protocol-type {
    type enumeration {
      enum GRE {
        value 0;
        description
          "Transport based on GRE.";
      }
      enum LDP {
        value 1;
        description
          "Transport based on LDP.";
      }
      enum BGP {
        value 2;
        description
          "Transport based on BGP.";

      }
      enum SR {
        value 3;
        description
          "Transport based on Segment Routing (SR)";
      }
      enum SR-TE {
        value 4;
        description
          "Transport based on SR for Traffic Engineering.";
      }
      enum RSVP-TE {
        value 5;
        description
          "Transport based on RSVP for Traffic Engineering";
      }
      enum unknown {
        value 6;
        description
          "Transport UNKNOWN";
      }
    }
    description
      "These attributes are used to identify underlying
       protocols when activating an L3VPN service.";
  }

  typedef area-address {
    type string {
      pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}';
    }
    description
      "This type defines the area address format.";
  }

  typedef isis-level {
    type enumeration {
      enum level1 {
        value 0;
        description
          "ISIS level 1";
      }
      enum level2 {
        value 1;
        description
          "ISIS level 2";
      }
      enum level1-2 {
        value 2;
        description
          "ISIS level 1 and 2";
      }
    }
    description
      "Defines the ISIS level for interface and system.";
  }

  typedef ie-type {
    type enumeration {
      enum import {
        value 0;
        description
          "Import a routing profile.";
      }
      enum export {
        value 1;
        description
          "Export a routing profile.";
      }
      enum both {
        value 2;
        description
          "Import/Export a routing profile.";
      }
    }
    description
      "Defines Import-Export routing profiles.
       Those profiles can be reused between VPN nodes.";
  }

  typedef operational-type {
    type enumeration {
      enum up {
        value 0;
        description
          "Operational status UP/Enabled.";
      }
      enum down {
        value 1;
        description
          "Operational status DOWN/Disabled.";
      }
      enum unknown {
        value 2;
        description
          "Operational status UNKNOWN.";

      }
    }
    description
      "This attribute is used to determine the
       status of a particular element.";
  }

  /* Identities */

  identity vpn-topology {
    description
      "Base identity for VPN topology.";
  }

  identity any-to-any {
    base vpn-topology;
    description
      "Identity for any-to-any VPN topology.";
  }

  identity hub-spoke {
    base vpn-topology;
    description
      "Identity for Hub-and-Spoke VPN topology.";
  }

  identity hub-spoke-disjoint {
    base vpn-topology;
    description
      "Identity for Hub-and-Spoke VPN topology
       where Hubs cannot communicate with each other.";
  }

  identity custom {
    base vpn-topology;
    description
      "Identity for CUSTOM VPN topology
       where Hubs can act as Spoke for certain part of
       the network or Spokes as Hubs.";
  }

  identity isis {
    base l3vpn-svc:routing-protocol-type;
    description
      "Identity for ISIS protocol type.";
  }

  identity pseudowire {
    base l3vpn-svc:site-network-access-type;
    description
      "Identity for pseudowire connections.";
  }

  identity loopback {
    base l3vpn-svc:site-network-access-type;
    description
      "Identity for loopback connections.";
  }

  identity encapsulation-type {
    description
      "Identity for the encapsulation type.";
  }

  identity untagged-int {
    base encapsulation-type;
    description
      "Identity for Ethernet type.";
  }

  identity tagged-int {
    base encapsulation-type;
    description
      "Identity        ...
                 ...

                 Figure 17: OPSF Routing Subtree Structure

   o  BGP: The model (Figure 18) allows to configure a BGP neighbor,
      including a set for parameters that are pertinent to be tweaked at
      the VLAN type.";
  }

  identity eth-inf-type {
    description
      "Identity network level for service customization purposes.  This
      container does not aim to include every BGP parameter; a
      comprehensive set of parameters belongs more to the Ethernet interface type.";
  }

  identity tagged {
    base eth-inf-type;
    description
      "Identity of BGP device
      model.  The following parameters are captured in Figure 18.  It is
      up to the tagged interface type.";
  }

  identity untagged {
    base eth-inf-type;
    description
      "Identity implementation to drive the corresponding BGP device
      configuration.

      *  'peer-autonomous-system': This parameter conveys the Customer's
         AS Number (ASN).

      *  'local-autonomous-system': This parameter is set of AS override
         is activated for this peer.

      *  'address-family': This attribute indicates the untagged interface type.";
  }

  identity lag {
    base eth-inf-type;
    description
      "Identity address-family
         of the LAG interface type.";
  }

  identity bearer-inf-type {
    description
      "Identity peer.  It can be set to IPv4, IPv6, or both address-
         families.

      *  'neighbor': The module supports supplying two neighbors (each
         for a given address-family) or one neighbor (if 'address-
         family' attribute is set to both IPv4 and IPv6 address-
         families).  A list of IP address(es) of the bearer interface type.";
  }

  identity port-id {
    base bearer-inf-type;
    description
      "Identity for BGP neighbor can be
         then conveyed in this parameter.

      *  'multihop': This attribute indicates the priority-tagged interface.";
  }

  identity lag-id {
    base bearer-inf-type;
    description
      "Identity for number of allowed IP
         hops between a BGP peer and a PE.

      *  'security': The authentication type will be driven by the priority-tagged interface.";
  }

  identity tagged-inf-type {
    description
      "Identity for
         implementation but the tagged interface type.";
  }

  identity priority-tagged {
    base tagged-inf-type;
    description
      "Identity for module supports any authentication that
         uses a key as a parameter.

      *  'as-override': If set, this parameter indicates whether AS
         override is enabled, i.e., replace the priority-tagged interface.";
  }

  identity qinq {
    base tagged-inf-type;
    description
      "Identity for ASN of the QinQ tagged interface.";
  }

  identity dot1q {
    base tagged-inf-type;
    description
      "Identity for peer
         specified in the dot1Q VLAN tagged interface.";
  }

  identity qinany {
    base tagged-inf-type;
    description
      "Identity for AS Path attribute with the QinAny tagged interface.";
  }
  identity vxlan {
    base tagged-inf-type;
    description
      "Identity for ASN identified by
         the VXLAN tagged interface.";
  }

  identity tag-type {
    description
      "Base identity 'local-autonomous-system' attribute.

      *  'default-route': This attribute controls whether default
         route(s) can be advertised to the peer.

      *  'bgp-max-prefix': This attribute is used to control how many
         prefixes can be received from a neighbor.  If reached, the BGP
         session will be teared down.

      *  'bgp-timer': Two timers can be captured in this container: (1)
         'hold-time' which all tag types are derived.";
  }

  identity c-vlan {
    base tag-type;
    description
      "A CVLAN tag, normally using is the 0x8100 Ethertype.";
  }

  identity s-vlan {
    base tag-type;
    description
      "An SVLAN tag.";
  }

  identity c-s-vlan {
    base tag-type;
    description
      "Using both a CVLAN tag and an SVLAN tag.";
  }

  identity vxlan-peer-mode {
    description
      "Base identity time interval that will be used for
         the VXLAN peer mode.";
  }

  identity static-mode {
    base vxlan-peer-mode;
    description
      "Identity HoldTimer (Section 4.2 of [RFC4271]) when establishing a
         BGP session. (2) 'keep-alive' which is the time interval for VXLAN access in
         the KeepAlive timer between a PE and a BGP peer (Section 4.4 of
         [RFC4271]).

                 ...
                 +--rw vpn-network-accesses
                 |  +--rw vpn-network-access* [id]
                 |     +--rw id
                 |     |       vpn-common:vpn-id
                 |     ...
                 |     +--rw ip-connection
                 |     |  ...
                 |     +--rw routing-protocols
                 |     |  +--rw routing-protocol* [id]
                 |     |     +--rw id                  string
                 |     |     +--rw type?               identityref
                 |     |     +--rw routing-profiles* [id]
                 |     |     |  +--rw id      leafref
                 |     |     |  +--rw type?   identityref
                 |     |     +--rw ospf {vpn-common:rtg-ospf}?
                 |     |     |  ...
                 |     |     +--rw bgp {vpn-common:rtg-bgp}?
                 |     |     |  +--rw peer-autonomous-system
                 |     |     |  |           inet:as-number
                 |     |     |  +--rw local-autonomous-system?
                 |     |     |  |       inet:as-number
                 |     |     |  +--rw address-family*
                 |     |     |  |      vpn-common:address-family
                 |     |     |  +--rw neighbor*
                 |     |     |  |       inet:ip-address
                 |     |     |  +--rw multihop?            uint8
                 |     |     |  +--rw security
                 |     |     |  |  +--rw auth-key?   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 description?               string
                 |     |     |  +--rw as-override?               boolean
                 |     |     |  +--rw default-route?             boolean
                 |     |     |  +--rw bgp-max-prefix
                 |     |     |  |  +--rw max-prefix?          uint32
                 |     |     |  |  +--rw warning-threshold?   decimal64
                 |     |     |  |  +--rw violate-action?    enumeration
                 |     |     |  |  +--rw restart-interval?    uint16
                 |     |     |  +--rw bgp-timer
                 |     |     |     +--rw keep-alive?   uint16
                 |     |     |     +--rw hold-time?    uint16
                 |     |     +--rw isis {vpn-common:rtg-isis}?
                 |     |     |  ...
                 |     |     +--rw static mode.";
  }

  identity bgp-mode {
    base vxlan-peer-mode;
    description
      "Identity for VXLAN access using BGP EVPN.";
  }

  identity bw-direction {
    description
      "Identity for the bandwidth direction.";
  }

  identity input-bw {
    base bw-direction;
    description
      "Identity for the input bandwidth.";
  }

  identity output-bw {
    base bw-direction;
    description
      "Identity for the output bandwidth.";
  }

  identity bw-type {
    description
      "Identity of the bandwidth type.";
  }

  identity bw-per-cos {
    base bw-type;
    description
      "Bandwidth is per CoS.";
  }

  identity bw-per-port {
    base bw-type;
    description
      "Bandwidth is per site network access.";
  }

  identity bw-per-site {
    base bw-type;
    description
      "Bandwidth is per site.  It is applicable
                 |     |     |  ...
                 |     |     +--rw rip {vpn-common:rtg-rip}?
                 |     |     |  ...
                 |     |     +--rw vrrp {vpn-common:rtg-vrrp}?
                 |     |        ...
                 |     +--rw service
                 |        ...
                 ...

                 Figure 18: BGP Routing Subtree Structure

   o  IS-IS: The model (Figure 19) allows the user to
       all configure IS-IS to
      run on the site network accesses within 'vpn-network-access' interface.  An IS-IS instance can
      run L1, L2, or both levels.

                     ...
                     +--rw vpn-network-accesses
                     |  +--rw vpn-network-access* [id]
                     |     +--rw id
                     |     |       vpn-common:vpn-id
                     |     ...
                     |     +--rw ip-connection
                     |     |  ...
                     |     +--rw routing-protocols
                     |     |  +--rw routing-protocol* [id]
                     |     |     +--rw id                  string
                     |     |     +--rw type?
                     |     |     |        identityref
                     |     |     +--rw routing-profiles* [id]
                     |     |     |  +--rw id      leafref
                     |     |     |  +--rw type?   identityref
                     |     |     +--rw ospf {vpn-common:rtg-ospf}?
                     |     |     |  ...
                     |     |     +--rw bgp {vpn-common:rtg-bgp}?
                     |     |     |  ...
                     |     |     +--rw isis {vpn-common:rtg-isis}?
                     |     |     |  +--rw address-family*
                     |     |     |  |       vpn-common:address-family
                     |     |     |  +--rw area-address
                     |     |     |  |       yang:dotted-quad
                     |     |     |  +--rw level?            identityref
                     |     |     |  +--rw metric?           uint16
                     |     |     |  +--rw process-id?       uint16
                     |     |     |  +--rw mode?             enumeration
                     |     |     |  +--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 static
                     |     |     |  ...
                     |     |     +--rw rip {vpn-common:rtg-rip}?
                     |     |     |  ...
                     |     |     +--rw vrrp {vpn-common:rtg-vrrp}?
                     |     |        ...
                     |     +--rw service
                     |        ...
                     ...

                Figure 19: IS-IS Routing Subtree Structure

   o  RIP: The module covers only a list of address-family as parameter.

   o  VRRP: The module covers only a site.";
  }

  identity bw-per-svc {
    base bw-type;
    description
      "Bandwidth is per VPN service.";
  }

  /* Groupings */

  grouping svc-transport-encapsulation {
    container underlay-transport {
      leaf-list type {
        type protocol-type;
  ordered-by user;
        description
          "Protocols used list of address-family as
      parameter.

   The module allows a user to deliver an L3VPN service.";
      }
      description
        "Container for the Transport Underlay.";
    }
    description
      "This grouping defines configure one or more IPv4 and/or IPv6
   static routes as depicted in Figure 20.

                       ...
                       +--rw vpn-network-accesses
                       |  +--rw vpn-network-access* [id]
                       |     +--rw id
                       |     |       vpn-common:vpn-id
                       |     ...
                       |     +--rw ip-connection
                       |     |  ...
                       |     +--rw routing-protocols
                       |     |  +--rw routing-protocol* [id]
                       |     |     +--rw id              string
                       |     |     +--rw type?      identityref
                       |     |     +--rw routing-profiles* [id]
                       |     |     |  +--rw id      leafref
                       |     |     |  +--rw type?   identityref
                       |     |     +--rw ospf {vpn-common:rtg-ospf}?
                       |     |     |  ...
                       |     |     +--rw bgp {vpn-common:rtg-bgp}?
                       |     |     |  ...
                       |     |     +--rw isis {vpn-common:rtg-isis}?
                       |     |     |  ...
                       |     |     +--rw static
                       |     |     |  +--rw cascaded-lan-prefixes
                       |     |     |     +--rw ipv4-lan-prefixes*
                       |     |     |     |       [lan next-hop]
                       |     |     |     |       {vpn-common:ipv4}?
                       |     |     |     |  +--rw lan
                       |     |     |     |  |       inet:ipv4-prefix
                       |     |     |     |  +--rw lan-tag?    string
                       |     |     |     |  +--rw next-hop
                       |     |     |     |          inet:ipv4-address
                       |     |     |     +--rw ipv6-lan-prefixes*
                       |     |     |             [lan next-hop]
                       |     |     |             {vpn-common:ipv6}?
                       |     |     |        +--rw lan
                       |     |     |        |       inet:ipv6-prefix
                       |     |     |        +--rw lan-tag?    string
                       |     |     |        +--rw next-hop
                       |     |     |                inet:ipv6-address
                       |     |     +--rw rip {vpn-common:rtg-rip}?
                       |     |     |  ...
                       |     |     +--rw vrrp {vpn-common:rtg-vrrp}?
                       |     |        ...
                       |     +--rw service
                       |        ...
                       ...

                Figure 20: Static Routing Subtree Structure

7.3.4.2.5.  Services

   The 'services' container specifies the type of underlay transport service parameters to apply
   for a given VPN service.";
  }

  grouping multicast-rp-group-cfg {
    choice group-format {
      mandatory true;
      case group-prefix {
        leaf group-address {
          type inet:ip-prefix;
          description
            "A single multicast group prefix.";
        }
      }
      case startend {
        leaf group-start {
          type inet:ip-address;
          description
            "The first multicast group address in
             the multicast group address range.";
        }
        leaf group-end {
          type inet:ip-address;
          description
            "The last network access (Figure 21).

                      ...
                      +--rw vpn-network-accesses
                      |  +--rw vpn-network-access* [id]
                      |     +--rw id
                      |     |       vpn-common:vpn-id
                      |     ...
                      |     +--rw service
                      |        +--rw svc-input-bandwidth     uint64
                      |        +--rw svc-output-bandwidth    uint64
                      |        +--rw svc-mtu                 uint16
                      |        +--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-profile
                      |        |     +--rw qos-profile* [profile]
                      |        |        +--rw profile      leafref
                      |        |        +--rw direction?   identityref
                      |        +--rw carrierscarrier
                      |        |       {vpn-common:carrierscarrier}?
                      |        |  +--rw signalling-type?   enumeration
                      |        +--rw multicast group address in {vpn-common:multicast}?
                      |           +--rw site-type?        enumeration
                      |           +--rw address-family?
                      |           |       vpn-common:address-family
                      |           +--rw protocol-type?    enumeration
                      |           +--rw remote-source?    boolean
                      ...

                   Figure 21: Services Subtree Structure

   The following attributes are defined:

   o  'svc-input-bandwidth': Indicates the multicast group address range.";
        }
      }
      description
        "Choice for multicast group format.";
    }
    description
      "This grouping defines multicast group or
       multicast groups for RP-to-group mapping.";
  }

  grouping vpn-service-multicast {
    container multicast {
      if-feature "l3vpn-svc:multicast";
      leaf enabled {
        type boolean;
        default "false";
        description
          "Enables multicast.";
      }
      leaf-list tree-flavor {
        type identityref {
          base l3vpn-svc:multicast-tree-type;
        }
        description
          "Type inbound bandwidth of tree to be used.";
      }
      container rp {
        container rp-group-mappings {
          list rp-group-mapping {
            key "id";
            leaf id {
              type uint16;
              description
                "Unique identifier for the mapping.";
            }
            container provider-managed {
              leaf enabled {
                type boolean;
                default "false";
                description
                  "Set
      connection (i.e., download bandwidth from the SP to true if the Rendezvous Point (RP)
                   must be a provider-managed node.  Set site).

   o  'svc-output-bandwidth': Indicates the outbound bandwidth of the
      connection (i.e., upload bandwidth from the site to false
                   if it is a customer-managed node.";
              }
              leaf rp-redundancy {
                type boolean;
                default "false";
                description
                  "If true, a redundancy mechanism for the RP
                   is required.";
              }
              leaf optimal-traffic-delivery {
                type boolean;
                default "false";
                description
                  "If true, SP).

   o  'svc-mtu': Indicates the SP must ensure that
                   traffic uses an optimal path.  An SP may use
                   Anycast RP or RP-tree-to-SPT switchover
                   architectures.";

              }
              container anycast {
                when "../rp-redundancy = 'true' and
                      ../optimal-traffic-delivery = 'true'" {
                    description
                      "Only applicable if
                       RP redundancy MTU at service level.  It can be the IP
      MTU or MPLS MTU, for example.

   o  'carrierscarrier': Groups a set of parameters that are used when
      CsC is enabled and delivery through
                       optimal path is activated.";
                }
                leaf local-address {
                  type inet:ip-address;
                  description
                    "IP local address such the use of BGP for PIM RP.
                     Usually, it corresponds signalling purposes
      [RFC8277].

   o  'multicast': Specifies the multicast mode and other service-
      related attributes such as the address-family.

   o  'qos': Is used to router
                     ID define QoS policies to apply on a given
      connection.  Classification can be based on many criteria such as:

      *  Layer 3: As shown in Figure 23, the model allow to classify
         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)
       |  |     |  |  |  |  ...
       |  |     |  |  |  +--:(ipv6)
       |  |     |  |  |     ...
       |  |     |  |  +--rw (l4)?
       |  |     |  |  +--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
       |  |     |  |  +--rw (l4)?
       |  |     |  |     +--:(tcp)
       |  |     |  |     |  ...
       |  |     |  |     +--:(udp)
       |  |     |  |        ...
       ...

                   Figure 22: QoS Subtree Structure (L3)

      *  Layer 4: As shown in Figure 23, TCP or primary address";
                }
                leaf-list rp-set-address {
                  type inet:ip-address;
                  description
                    "Address other RP routers
                     that share the same RP IP address.";
                }
                description
                  "PIM Anycast-RP parameters.";
              }
              description
                "Parameters for a provider-managed RP.";
            }
            leaf rp-address {
              when "../provider-managed/enabled = 'false'" {
                description
                  "Relevant when the RP is not provider-managed.";
              }
              type inet:ip-address;
              mandatory true;
              description
                "Defines the address of the RP.
                 Used if the RP is customer-managed.";
            }
            container groups {
              list group {
                key "id";
                leaf id {
                  type uint16;
                  description
                    "Identifier for the group.";
                }
                uses multicast-rp-group-cfg;
                description
                  "List of multicast groups.";
              }
              description
                "Multicast groups associated with the RP.";
            }
            description
              "List of RP-to-group mappings.";
          }
          description
            "RP-to-group mappings parameters.";
        }
        container rp-discovery {
          leaf rp-discovery-type {
            type identityref {
              base l3vpn-svc:multicast-rp-discovery-type;
            }
            default "l3vpn-svc:static-rp";
            description
              "Type of RP discovery used.";
          }
          container bsr-candidates {
            when "derived-from-or-self(../rp-discovery-type, "
               + "'l3vpn-svc:bsr-rp')" {
              description
                "Only applicable if discovery type
                 is BSR-RP.";
            }
            leaf-list bsr-candidate-address {
              type inet:ip-address;
              description
                "Address of candidate Bootstrap Router (BSR).";
            }
            description
              "Container for List of Customer
               BSR candidate's addresses.";
          }
          description
            "RP discovery parameters.";
        }
        description
          "RP parameters.";
      }
      container msdp {
        if-feature "msdp";
        leaf UDP-related match
         crietria can be specified.

  +--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)
  |  |     |  |     |  +--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 23: QoS Subtree Structure (L4)

      *  Application match

7.3.4.3.  Multicast

   Multicast MAY be enabled { for a particular vpn-network-node (see
   Figure 24).

   The model supports a single type boolean;
          default "false";
          description
            "If true, of tree (Any-Source Multicast Source Discovery Protocol (MSDP)
             protocol (ASM),
   Source-Specific Multicast (SSM), or bidirectional).

   When ASM is activated.";
        }
        leaf peer {
          type inet:ip-address;
          description
            "IP address of used, the MSDP peer.";
        }
        leaf local-address {
          type inet:ip-address;
          description
            "IP address 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 local end. This local '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 on the node.";
        }
        description
          "MSDP parameters.";
      }
      description
        "Multicast global parameters for using the VPN service.";
    }
    description
      "Grouping for multicast VPN definition.";
  }

  grouping vpn-service-mpls { 'rp-address' leaf carrierscarrier {
      if-feature "l3vpn-svc:carrierscarrier";
      type boolean;
      default "false";
      description
        "The VPN
   otherwise no RP address is using CsC, and so MPLS needed.

   The model supports RP redundancy through the 'rp-redundancy' leaf.
   How the redundancy is required.";
    }
    description
      "Grouping for MPLS Carriers'Carrier definition.";
  }

  grouping operational-requirements {
    leaf requested-site-start {
      type yang:date-and-time;
      description
        "Optional leaf indicating requested date achieved is out of scope and
         time when 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 service at implementation must use any mechanism to provide a particular site more optimal
   traffic delivery for the customer.  Anycast is
         expected one of the mechanisms
   to start.";
    }
    leaf requested-site-stop {
      type yang:date-and-time;
      description
        "Optional leaf indicating requested date enhance RPs redundancy, resilience against failures, and
         time when to
   recover from failures quickly.

   For redundancy purposes, Multicast Source Discovery Protocol (MSDP)
   [RFC3618] may be enabled and used to share the service at a particular site state about sources
   between multiple RPs.  The purpose of MSDP in this context is
         expected to stop.";
    }
    description
      "This grouping defines some operational
       parameters.";
  }

  grouping status-timestamp {
    leaf status {
      type operational-type;
      description
        "Operations status";
    }
    leaf timestamp {
      type yang:date-and-time;
      description
        "Indicates the actual date and time when
   enhance the service actually started (UP) or
         stopped (DOWN).";
    }
    description
      "This grouping defines some operational
       parameters for robustness of the service.";
  }

  grouping service-status {
    container service-status {
      container admin {
        uses status-timestamp;
        description
          "Administrative service status.";
      }
      container ops {
        config false; 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.

                      ...
                      +--rw vpn-network-accesses
                      |  +--rw vpn-network-access* [id]
                      |     +--rw id
                      |     ..
                      +--rw multicast {vpn-common:multicast}?
                         +--rw enabled?       boolean
                         +--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 msdp {msdp}?
                            +--rw enabled?         boolean
                            +--rw peer?            inet:ip-address
                            +--rw local-address?   inet:ip-address

                  Figure 24: Multicast Subtree Structure

8.  Layer 3 Network Model

   This module uses status-timestamp;
        description
          "Operational service status.";
      }
      description
        "Service status.";
    }
    description
      "Service status grouping. Reused types defined in
       vpn-node [RFC6991] and vpn-network-access.";
  }
  grouping site-service-basic {
    leaf svc-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 svc-output-bandwidth groupings defined in
   [RFC8519].

<CODE BEGINS>  file "ietf-l3vpn-ntw@2020-09-15.yang"
module ietf-l3vpn-ntw {
      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 svc-mtu
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw";
  prefix l3nm;

  import ietf-vpn-common {
      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 'svc-mtu' leaf will refer to the
         MPLS MTU and not to the IP MTU.";
    }
    description
      "Defines basic service parameters for a site.";
    prefix vpn-common;
    reference
      "RFC UUUU: A Layer 2/3 VPN Common YANG Model";
  }

  grouping site-protection {
    container traffic-protection {
      if-feature "l3vpn-svc:fast-reroute";
      leaf enabled
  import ietf-inet-types {
        type boolean;
        default "false";
        description
          "Enables traffic protection
    prefix inet;
    reference
      "Section 4 of access link.";
      }
      description
        "Fast Reroute service parameters for the site.";
    }
    description
      "Defines protection service parameters for a site."; RFC 6991";
  }
  grouping site-service-mpls {
    container carrierscarrier {
      if-feature "l3vpn-svc:carrierscarrier";
      leaf signalling-type {
        type enumeration {
          enum ldp
  import ietf-yang-types {
            description
              "Use LDP as the signalling protocol
               between the PE and the CE.  In this case,
               an IGP routing protocol must also be activated.";
    prefix yang;
    reference
      "Section 3 of RFC 6991";
  }
          enum bgp
  import ietf-packet-fields {
            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.";
    prefix pf;
    reference
      "RFC 8277: Using BGP to Bind MPLS Labels to
                         Address Prefixes";
          }
        }
        default "bgp";
        description
          "MPLS signalling type."; 8519: YANG Data Model for Network Access
                 Control Lists (ACLs)";
  }

  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>
    ";
  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 MPLS service using
         an IP VPN to carry its traffic).";
    }
    description
      "Defines MPLS service parameters for YANG module defines a site.";
  }

  grouping ports {
    choice source-port {
      container source-port-range-or-operator {
        uses packet-fields:port-range-or-operator;
        description
          "Source port definition.";
      }
      description
        "Choice generic network-oriented model
     for the configuration of Layer 3 Virtual Private Networks.

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

     Redistribution and use in source port and binary forms, with or referring
     without modification, is permitted pursuant to, and subject to
         a group of source port numbers.";
    }
    choice destination-port {
      container destination-port-range-or-operator {
        uses packet-fields:port-range-or-operator;
        description
          "Destination port definition.";
      }
      description
        "Choice
     the license terms contained in, the Simplified BSD License set
     forth in Section 4.c of specifying a destination port or referring the IETF Trust's Legal Provisions
     Relating to a group IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of destination port numbers.";
    }
    description
      "Choice this YANG module is part of specifying a source or destination port numbers.";
  }

  grouping site-service-qos-profile {
    container qos {
      if-feature "l3vpn-svc:qos";
      container qos-classification-policy {
        list rule {
          key "id";
          ordered-by user;
          leaf id {
            type string;
            description
              "A description identifying RFC XXXX
     (https://www.rfc-editor.org/info/rfcXXXX); see the
               qos-classification-policy rule.";
          }
          choice match-type {
            default "match-flow";
            case match-flow {
              //uses l3vpn-svc:flow-definition;
              choice l3 {
                container ipv4 {
                  uses packet-fields:acl-ip-header-fields;
                  uses packet-fields:acl-ipv4-header-fields;
                  description
                    "Rule set that matches IPv4 header.";
                }
                container ipv6 {
                  uses packet-fields:acl-ip-header-fields;
                  uses packet-fields:acl-ipv6-header-fields;
                  description
                    "Rule set that matches IPv6 header.";
                }
                description
                  "Either IPv4 or IPv6.";
              }
              choice l4 {
                container tcp RFC itself
     for full legal notices.";

  revision 2020-09-15 {
                  uses packet-fields:acl-tcp-header-fields;
                  uses ports;
    description
                    "Rule set that matches TCP header.";
      "Initial revision.";
    reference
      "RFC XXXX: A Layer 3 VPN Network YANG Model";
  }
                container udp

  /* Features */

  feature msdp {
                  uses packet-fields:acl-udp-header-fields;
                  uses ports;
    description
                    "Rule set
      "This feature indicates that matches UDP header.";
                }
                description
                  "Can be TCP or UDP";
              } Multicast Source
       Discovery Protocol (MSDP) capabilities are
       supported by the VPN.";
    reference
      "RFC 3618: Multicast Source Discovery Protocol (MSDP)";
  }
            case match-application {
              leaf match-application

  /* Typedefs */

  typedef area-address {
    type identityref string {
                  base l3vpn-svc:customer-application;
      pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}';
    }
    description
                  "Defines
      "This type defines the application to match.";
              } area address format.";
  }

  /* Identities */

  identity address-allocation-type {
    description
              "Choice
      "Base identity for classification."; address-allocation-type for
       PE-CE link.";

  }
          leaf target-class-id

  identity provider-dhcp {
            type string;
    base address-allocation-type;
    description
              "Identification of the class of service.
               This identifier is internal
      "The Provider's network provides a DHCP service
       to the administration."; customer.";
  }

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

  identity provider-dhcp-slaac {
    base address-allocation-type;
    description
          "Configuration of
      "The Provider's network provides a DHCP service to
       the traffic classification policy."; customer, as well as IPv6 Stateless Address
       Autoconfiguration (SLAAC).";
    reference
      "RFC 7527: IPv6 Stateless Address Autoconfiguration";
  }
      container qos-profile {
        list qos-profile

  identity static-address {
          key profile;
    base address-allocation-type;
    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";
      "The Provider-to-customer addressing is static.";
  }

  identity slaac {
    base address-allocation-type;
    description
                "QoS profile to be used.";
      "Use IPv6 SLAAC.";
    reference
      "RFC 7527: IPv6 Stateless Address Autoconfiguration";
  }
            leaf direction

  identity isis-level {
              type identityref
    description
      "Defines the IS-IS level for interface
       and system.";
  }

  identity level1 {
    base l3vpn-svc:qos-profile-direction; isis-level;
    description
      "IS-IS level 1.";
  }
              default "l3vpn-svc:both";

  identity level2 {
    base isis-level;
    description
                "The direction to which the QoS profile
                 is applied.";
      "IS-IS level 2.";
  }

  identity level1-2 {
    base isis-level;
    description
      "IS-IS levels 1 and 2.";
  }

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

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

  identity lag-id {
    base bearer-inf-type;
    description
      "This grouping defines QoS parameters
      "Identity for a site."; the lag-tagged interface.";
  }

  /* Groupings */

  grouping site-security-authentication security-params {
    container authentication security {
      leaf auth-key {
        type string;
        description
        "Authentication parameters.";
          "MD5 authentication password for the connection
           towards the customer edge.";
      }
      description
      "This grouping defines authentication parameters
        "Container for aggregating any security parameter
          for routing sessions between a site."; PE and a CE.";
    }
    description
      "Grouping to define a set of security parameters";
  }

  grouping site-security-encryption ports {
    container encryption
    choice source-port {
      if-feature "l3vpn-svc:encryption";
      leaf enabled
      container source-port-range-or-operator {
        type boolean;
        default "false";
        uses pf:port-range-or-operator;
        description
          "If true, traffic encryption on the connection
           is required. It is disabled, otherwise.";
          "Source port definition.";
      }
      leaf layer {
        when "../enabled = 'true'" {
      description
            "Require
        "Choice of specifying the source port or
          referring to a value for layer when enabled
             is true."; group of source port numbers.";
    }
        type enumeration
    choice destination-port {
          enum layer2
      container destination-port-range-or-operator {
        uses pf:port-range-or-operator;
        description
              "Encryption will occur at Layer 2.";
          "Destination port definition.";
      }
          enum layer3 {
      description
              "Encryption will occur at Layer 3.
               For example, IPsec may be used when
        "Choice of specifying a customer requests Layer 3 encryption.";
          } destination port or
         referring to a group of destination port
         numbers.";
    }
    description
          "Layer on which encryption is applied.";
      "Choice of specifying a source or destination
       port numbers.";
  }

  /* Main Blocks */
  /* Main l3nm */

  container l3vpn-ntw {
    container vpn-profiles {
      uses vpn-common:vpn-profile-cfg;
      description
        "Container for CE-PE security encryption.";
        "Contains a set of valid VPN Profiles to
         reference in the VPN service.";
    }
    container encryption-profile vpn-services {
      choice profile
      list vpn-service {
        case provider-profile
        key "vpn-id";
        uses vpn-common:service-status;
        uses vpn-common:vpn-description;
        leaf l3sm-vpn-id {
          type vpn-common:vpn-id;
          description
            "Pointer to the parent L3SM service,
             if any.";
        }
        leaf profile-name vpn-type {
          type leafref identityref {
              path "/l3vpn-ntw/vpn-profiles/"
                 + "valid-provider-identifiers"
                 + "/encryption-profile-identifier/id";
            base vpn-common:vpn-signaling-type;
          }
          description
              "Name of
            "Indicates the SP profile to be applied.";
          }
        }
        case customer-profile { service type";
        }
        leaf algorithm vpn-service-topology {
          type string;
            description
              "Encryption algorithm to be used.";
          } identityref {
            base vpn-common:vpn-topology;
          }
          default "vpn-common:any-to-any";
          description
          "Choice for encryption profile.";
            "VPN service topology.";
        }
      choice key-type
        container ie-profiles {
        default "psk";
        case psk
          list ie-profile {
            key "ie-profile-id";
            leaf preshared-key ie-profile-id {
              type string;
              description
              "Pre-Shared Key (PSK) coming from the customer.";
          }
        }
        description
          "Choice of encryption profile.
           The encryption profile can be the provider
                "IE profile
           or customer profile."; id.";
            }
            uses vpn-common:rt-rd;
            description
        "Container
              "List for encryption Imort/Export profile.";
          }
          description
      "This grouping defines encryption parameters
            "Container for
         a site."; Import/Export profiles.";
        }

  grouping site-routing {
        uses vpn-common:svc-transport-encapsulation;
        container routing-protocols vpn-nodes {
          description
            "Container for VPN nodes.";
          list routing-protocol vpn-node {
            key "id"; "vpn-node-id";
            leaf id vpn-node-id {
              type string;
          description
            "Unique identifier for routing protocol.";
        }
        leaf type union {
                type identityref {
            base l3vpn-svc:routing-protocol-type; vpn-common:vpn-id;
                type uint32;
              }
              description
                "Type of routing protocol."; STRING or NUMBER Service-Id.";
            }
        list routing-profiles {
          key "id";
            leaf id local-autonomous-system {
              type leafref {
              path "/l3vpn-ntw/vpn-profiles/"
                 + "valid-provider-identifiers"
                 + "/routing-profile-identifier/id";
            } inet:as-number;
              description
              "Routing profile to be used.";
                "Provider's AS number in case the customer
                 requests BGP routing.";
            }
            leaf type description {
              type ie-type;
            description
              "Import, export or both.";
          } string;
              description
            "Import or Export profile reference";
        }
        container ospf {
          when "derived-from-or-self(../type, 'l3vpn-svc:ospf')" {
                "Textual description
              "Only applies when protocol is OSPF."; of the VPN node.";
            }
          if-feature "l3vpn-svc:rtg-ospf";
          leaf-list address-family
            leaf ne-id {
              type l3vpn-svc:address-family;
            min-elements 1; string;
              description
              "If OSPF is used on this site, this node
               contains a configured value.  This
                "Unique identifier of the network element
                 where the VPN node
               contains at least one address family
               to be activated."; is deployed.";
            }
            leaf area-address router-id {
              type yang:dotted-quad;
            mandatory true; inet:ip-address;
              description
              "Area
                "The router-id information can be an IPv4
                 or IPv6 address.";
            }
            leaf metric address-family {
              type uint16;
            default "1"; vpn-common:address-family;
              description
              "Metric of the PE-CE link.  It is
                "The address family used
               in the routing state calculation and
               path selection."; for router-id
                 information.";
            }
          /* Extension */
            leaf mtu node-role {
              type uint16; identityref {
                base vpn-common:role;
              }
              default "vpn-common:any-to-any-role";
              description
              "Maximum transmission unit for a given
               OSPF link.";
                "Role of the VPN node in the IP VPN.";
            }
            uses vpn-common:rt-rd;
            uses vpn-common:service-status;
            leaf process-id node-ie-profile {
              type uint16; leafref {
                path "/l3vpn-ntw/vpn-services/"
                   + "vpn-service/ie-profiles/"
                   + "ie-profile/ie-profile-id";
              }
              description
              "Process id of the OSPF CE-PE connection.";
                "Node's Import/Export profile.";
            }
            uses security-params;
          /* End of Extension */ vpn-common:vpn-node-group;
            container sham-links vpn-network-accesses {
            if-feature "rtg-ospf-sham-link";
              list sham-link vpn-network-access {
                key "target-site"; "id";
                leaf target-site id {
                  type l3vpn-svc:svc-id; vpn-common:vpn-id;
                  description
                  "Target site
                    "Identifier for the sham link connection.
                   The site is referred to by its ID."; access.";
                }
                leaf metric port-id {
                  type uint16;
                default "1"; vpn-common:vpn-id;
                  description
                  "Metric of the sham link.  It is used in
                    "Identifier for the routing state calculation and path
                   selection.  The default value is set
                   to 1.";
              }
              description
                "Creates a sham link with another site.";
            }
            description
              "List of sham links."; network access.";
                }
                leaf description
            "OSPF-specific configuration.";
        }
        container bgp {
          when "derived-from-or-self(../type, 'l3vpn-svc:bgp')" {
                  type string;
                  description
              "Only applies when protocol is BGP.";
                    "Textual description of a network access.";
                }
          if-feature "l3vpn-svc:rtg-bgp";
                uses vpn-common:service-status;
                leaf peer-autonomous-system vpn-network-access-type {
                  type inet:as-number;
            mandatory true; identityref {
                    base vpn-common:site-network-access-type;
                  }
                  default "vpn-common:point-to-point";
                  description
              "Customer AS number in case
                    "Describes the customer
               requests BGP routing."; type of connection, e.g.,
                     point-to-point or multipoint.";
                }
                container connection {
                  leaf local-autonomous-system encapsulation-type {
                    type inet:as-number;
            description
              "Local-AS overwrite.";
          }
          leaf-list address-family identityref {
            type l3vpn-svc:address-family;
            min-elements 1;
            description
              "If BGP is used on this site, this node
               contains a configured value.  This node
               contains at least one address family
               to be activated.";
                      base vpn-common:encapsulation-type;
                    }
          /*  Extension  */
          leaf-list neighbor {
            type inet:ip-address;
                    default "vpn-common:untagged-int";
                    description
              "IP address(es) of
                      "Encapsulation type.  By default,
                       the BGP neighbor. An IPv4
               and IPv6 neighbors may be indicated if
               two sessions will be used for IPv4 and IPv6."; encapsulation type is set to
                       'untagged'.";
                  }
                  container logical-interface {
                    leaf multihop peer-reference {
                      type uint8; uint32;
                      description
              "Describes
                        "Specify the number associated logical peer
                         interface";
                    }
                    description
                      "Reference of hops allowed between a given BGP neighbor and the PE router."; logical interface
                       type.";
                  }
          uses security-params;
          uses status-params;
                  container tagged-interface {
                    leaf description type {
                      type string;
            description
              "Includes a identityref {
                        base vpn-common:encapsulation-type;
                      }
                      default "vpn-common:priority-tagged";
                      description of
                        "Tagged interface type.  By default,
                         the BGP session.
               Such description is meant to be used for
               diagnosis purposes. The semantic type of the description tagged interface is local to an implementation.";
          }
          /* End- Extension  */
          description
            "BGP-specific configuration.";
                         'priority-tagged'.";
                    }
                    container isis dot1q-vlan-tagged {
                      when "derived-from-or-self(../type, 'l3vpn-ntw:isis')" "
                         + "'vpn-common:dot1q')" {
                        description
                          "Only applies when protocol the type of the
                           tagged interface is ISIS."; 'dot1q'.";
                      }
                      if-feature "rtg-isis";
          leaf-list address-family "vpn-common:dot1q";
                      leaf tag-type {
                        type l3vpn-svc:address-family;
            min-elements 1; identityref {
                          base vpn-common:tag-type;
                        }
                        default "vpn-common:c-vlan";
                        description
              "If ISIS
                          "Tag type.  By default, the tag
                           type is used on this site, this node
               contains a configured value.  This node
               contains at least one address family
               to be activated."; 'c-vlan'.";
                      }
                      leaf area-address cvlan-id {
                        type area-address;
            mandatory true; uint16;
                        description
              "Area address.";
                          "VLAN identifier.";
                      }
          leaf level
                      description
                        "Tagged interface.";
                    }
                    container priority-tagged {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:priority-tagged')" {
            type isis-level;
                        description
              "level1, level2 or level1-2";
                          "Only applies when the type of the
                           tagged interface is
                           'priority-tagged'.";
                      }
                      leaf metric tag-type {
                        type uint16; identityref {
                          base vpn-common:tag-type;
                        }
                        default "1"; "vpn-common:c-vlan";
                        description
              "Metric of
                          "Tag type.  By default, the PE-CE link.  It tag
                           type is used
               in the routing state calculation and
               path selection."; 'c-vlan'.";
                      }
          leaf process-id
                      description
                        "Priority tagged.";
                    }
                    container qinq {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:qinq')" {
            type uint16;
                        description
              "Process id
                          "Only applies when the type of
                           the ISIS CE-PE connection."; tagged interface is 'qinq'.";
                      }
                      if-feature "vpn-common:qinq";
                      leaf mode tag-type {
                        type enumeration {
              enum active identityref {
                          base vpn-common:tag-type;
                        }
                        default "vpn-common:c-s-vlan";
                        description
                  "Interface sends or receives ISIS protocol
                   control packets.";
                          "Tag type.  By default, the tag
                           type is 'c-s-vlan'.";
                      }
              enum passive
                      leaf svlan-id {
                        type uint16;
                        mandatory true;
                        description
                  "Suppresses the sending of ISIS routing updates
                   through the specified interface.";
              }
                          "SVLAN identifier.";
                      }
            default "active";
                      leaf cvlan-id {
                        type uint16;
                        mandatory true;
                        description
              "ISIS interface mode type.";
                          "CVLAN identifier.";
                      }
          uses status-params;
                      description
            "ISIS-specific configuration.";
                        "QinQ.";
                    }
                    container static qinany {
                      when "derived-from-or-self(../type, 'l3vpn-svc:static')" "
                         + "'vpn-common:qinany')" {
                        description
                          "Only applies when protocol is static.
               BGP activation requires the SP to know the address type of the customer peer.  When
               BGP
                           tagged interface is enabled, the 'static-address'
               allocation type for the IP connection
               MUST be used."; 'qinany'.";

                      }
          container cascaded-lan-prefixes {
            list ipv4-lan-prefixes {
                      if-feature "l3vpn-svc:ipv4";
              key "lan next-hop"; "vpn-common:qinany";
                      leaf lan tag-type {
                        type inet:ipv4-prefix;
                description
                  "LAN prefixes.";
              }
              leaf lan-tag identityref {
                type string;
                          base vpn-common:tag-type;
                        }
                        default "vpn-common:s-vlan";
                        description
                  "Internal
                          "Tag type.  By default, the tag to be used in VPN policies."; type
                           is 's-vlan'.";
                      }
                      leaf next-hop svlan-id {
                        type inet:ipv4-address; uint16;
                        mandatory true;
                        description
                  "Next-hop address to use on the customer side.";
                          "Service VLAN ID.";
                      }
                      description
                "List of LAN prefixes
                        "Container for the site."; QinAny.";
                    }
            list ipv6-lan-prefixes
                    container vxlan {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:vxlan')" {
                        description
                          "Only applies when the type of the
                           tagged interface is 'vxlan'.";
                      }
                      if-feature "l3vpn-svc:ipv6";
              key "lan next-hop"; "vpn-common:vxlan";
                      leaf lan vni-id {
                        type inet:ipv6-prefix; uint32;
                        mandatory true;
                        description
                  "LAN prefixes.";
                          "VXLAN Network Identifier (VNI).";
                      }
                      leaf lan-tag peer-mode {
                        type string; identityref {
                          base vpn-common:vxlan-peer-mode;
                        }
                        default "vpn-common:static-mode";
                        description
                  "Internal tag
                          "Specifies the VXLAN access mode.
                           By default, the peer mode is set
                           to be used in VPN policies."; 'static-mode'.";
                      }
                      list peer-list {
                        key "peer-ip";
                        leaf next-hop peer-ip {
                          type inet:ipv6-address; inet:ip-address;
                          description
                  "Next-hop address to use on the customer side.";
                            "Peer IP.";
                        }
                        description
                          "List of LAN prefixes for the site."; peer IP addresses.";
                      }
                      description
              "LAN prefixes from the customer.";
                        "QinQ.";
                    }
                    description
                      "Container for tagged interfaces.";
                  }
                  container bearer {
                    leaf bearer-reference {
                      if-feature "vpn-common:bearer-reference";
                      type string;
                      description
            "Configuration specific to static routing.";
                        "This is an internal reference for*
                         the SP.";
                    }
                    container rip pseudowire {
          when "derived-from-or-self(../type, 'l3vpn-svc:rip')"
                      leaf vcid {
                        type uint32;
                        description
              "Only applies when the protocol is RIP.  For IPv4,
               the model assumes that RIP version 2 is used.";
                          "PW or VC identifier.";
                      }
          if-feature "l3vpn-svc:rtg-rip";
          leaf-list address-family
                      leaf far-end {
                        type l3vpn-svc:address-family;
            min-elements 1; union {
                          type uint32;
                          type inet:ipv4-address;
                        }
                        description
              "If RIP is used on this site, this node
               contains a configured value.  This node
               contains at least one address family
               to be activated.";
                          "SDP/Far End/LDP neighbour reference.";
                      }
                      description
            "Configuration specific to RIP routing.";
                        "Pseudowire termination parameters";
                    }
                    container vrrp vpls {
          when "derived-from-or-self(../type, 'l3vpn-svc:vrrp')"
                      leaf vcid {
                        type union {
                          type uint32;
                          type string;
                        }
                        description
              "Only applies when protocol is VRRP.";
                          "VCID identifier, IRB/RVPPLs interface
                           supported using string
                           format.";
                      }
          if-feature "l3vpn-svc:rtg-vrrp";
          leaf-list address-family
                      leaf far-end {
                        type l3vpn-svc:address-family;
            min-elements 1;
            description
              "If VRRP is used on this site, this node
               contains a configured value.  This node contains
               at least one address family to be activated."; union {
                          type uint32;
                          type inet:ipv4-address;
                        }
                        description
            "Configuration specific to VRRP routing.";
                          "SDP/Far End/LDP Neighbour reference.";
                      }
                      description
          "List of routing protocols used on
           the site.  This list can be augmented.";
                        "Pseudowire termination parameters";
                    }
                    description
                      "Defines routing protocols."; physical properties of a site
                       attachment.";
                  }
                  description
      "Grouping for routing protocols.";
                    "Encapsulation types";
                }

  grouping site-attachment-ip-connection {
                container ip-connection {
                  container ipv4 {
                    if-feature "l3vpn-svc:ipv4"; "vpn-common:ipv4";
                    leaf address-allocation-type {
                      type identityref {
                        base l3vpn-svc:address-allocation-type; address-allocation-type;
                      }
                      must "not(derived-from-or-self(current(), 'l3vpn-svc:slaac')"
             + "
                         + "'slaac') or derived-from-or-self(current(), " derived-from-or-self(current(),"
                         + "'l3vpn-svc:provider-dhcp-slaac'))" " 'provider-dhcp-slaac'))" {
                        error-message "SLAAC is only applicable to
                                      IPv6";
                      }
                      description
                        "Defines how addresses are allocated.
                         If there is no value for the address
                         allocation type, then IPv4 is not enabled.";
                    }
        container
                    choice allocation-type {
                      case provider-dhcp {
                        when "derived-from-or-self(../address-allocation-type, " "derived-from-or-self(./address-"
                           + "'l3vpn-svc:provider-dhcp')" "allocation-type, 'provider-dhcp')" {
                          description
                            "Only applies when addresses are
                             allocated by DHCP.";
                        }
                        leaf provider-address {
                          type inet:ipv4-address;
                          description
                            "Address of provider side.

                             If provider-address is not specified,
                             then prefix length should not be
                             specified either.

                             It also implies provider-dhcp
                             allocation is not enabled.

                             If provider-address is specified,
                             then the prefix length may or
                             may not be specified.";
                        }
                        leaf prefix-length {
                          type uint8 {
                            range "0..32";
                          }
                          must '(../provider-address)' {
                            error-message
                              "If the prefix length is specified,
                               provider-address must also be
                               specified.";
                            description
                              "If the prefix length is specified,
                               provider-address must also be
                               specified.";
                          }
                          description
                            "Subnet prefix length expressed in bits.
                             If not specified, or specified as zero,
                             this means the customer leaves the actual
                             prefix length value to the provider.";
                        }
                        choice address-assign {
                          default "number";
                          case number {
                            leaf number-of-dynamic-address {
                              type uint16;
                              default "1";
                              description
                                "Describes the number of IP
                                 addresses the customer requires.";
                            }
                          }
                          case explicit {
                            container customer-addresses {
                              list address-group {
                                key "group-id";
                                leaf group-id {
                                  type string;
                                  description
                                    "Group-id for the address range
                                     from start-address to
                                     end-address.";
                                }
                                leaf start-address {
                                  type inet:ipv4-address;
                                  description
                                    "First address.";
                                }
                                leaf end-address {
                                  type inet:ipv4-address;
                                  description
                                    "Last address.";
                                }
                                description
                                  "Describes IP addresses allocated by
                                   DHCP.

                                   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.";
                              }
                              description
                                "Container for customer addresses is
                                 allocated by DHCP.";
                            }
                          }
                          description
                            "Choice for the way to assign
                             addresses.";
                        }
                        description
                          "DHCP allocated addresses related
                           parameters.";
                      }
        container
                      case dhcp-relay {
                        when "derived-from-or-self(../address-allocation-type, " "derived-from-or-self(./address-allocation"
                           + "'l3vpn-svc:provider-dhcp-relay')" "-type, 'provider-dhcp-relay')" {
                          description
                            "Only applies when provider is required to
                             implement DHCP relay function.";

                        }
                        leaf provider-address dr-provider-address {
                          type inet:ipv4-address;
                          description
                            "Address of provider side.

                             If provider-address is
                             not specified, then prefix length
                             should not be specified either.

                             It also implies provider-dhcp
                             allocation is not enabled.

                             If provider-address is specified,
                             then prefix length may or may
                             not be specified.";
                        }
                        leaf prefix-length dr-prefix-length {
                          type uint8 {
                            range "0..32";
                          }
                          must '(../provider-address)' '(../dr-provider-address)' {
                            error-message
                              "If prefix length is specified,
                               provider-address must also be
                               specified.";
                            description
                              "If prefix length is specified,
                               provider-address must also be
                               specified.";
                          }
                          description
                            "Subnet prefix length expressed in bits.

                             If not specified, or specified as zero,
                             this means the customer leaves the
                             actual prefix  length value
                             to the provider.";
                        }
                        container customer-dhcp-servers {
                          leaf-list server-ip-address {
                            type inet:ipv4-address;
                            description
                              "IP address of customer DHCP
                               server.";
                          }
                          description
                            "Container for list of customer
                             DHCP servers.";
                        }
                        description
                          "DHCP relay provided by operator.";
                      }
        container
                      case static-addresses {
                        when "derived-from-or-self(../address-allocation-type, " "derived-from-or-self(./address-allocation"
                           + "'l3vpn-svc:static-address')" "-type, 'static-address')" {
                          description
                            "Only applies when protocol address allocation
                            type is static.";
                        }
                        leaf primary-address {
                          type leafref {
                            path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/"
                 + "vpn-node/vpn-network-accesses/vpn-network-access/"
                 + "ip-connection/ipv4/static-addresses/address/"
                 + "address-id"; "../address/address-id";
                          }
                          description
                            "Principal address of the connection.";
                        }
                        list address {
                          key "address-id";
                          leaf address-id {
                            type string;
                            description
                              "IPv4 Address";
                          }
                          leaf provider-address s-provider-address {
                            type inet:ipv4-address;
                            description
                              "IPv4 Address List of the provider side.
                               When the protocol allocation type is
                               static, the provider address must be
                               configured.";
                          }
                          leaf customer-address s-customer-address {
                            type inet:ipv4-address;
                            description
                              "IPv4 Address of customer side.";
                          }
                          leaf prefix-length s-prefix-length {
                            type uint8 {
                              range "0..32";
                            }
                            description
                              "Subnet prefix length expressed
                               in bits. It is applied to both
                               provider-address and customer-address.";
                          }
                          description
                            "Describes IPv4 addresses used.";
                        }
                        description
                          "Describes IPv4 addresses used.";
                      }
                      description
                        "Choice the address allocation.";
                    }
                    description
                      "IPv4-specific parameters.";
                  }
                  container ipv6 {
                    if-feature "l3vpn-svc:ipv6"; "vpn-common:ipv6";
                    leaf address-allocation-type {
                      type identityref {
                        base l3vpn-svc:address-allocation-type; address-allocation-type;
                      }
                      description
                        "Defines how addresses are allocated.
                         If there is no value for the address
                         allocation type, then IPv6 is
                         not enabled.";
                    }
        container
                    choice allocation-type {
                      choice provider-dhcp {
                        when "derived-from-or-self(../address-allocation-type, " "derived-from-or-self(./address-allo"
                           + "'l3vpn-svc:provider-dhcp') "cation-type, 'provider-dhcp') "
                           + "or derived-from-or-self(../address-allocation-type, " derived-from-or-self(./address-allo"
                           + "'l3vpn-svc:provider-dhcp-slaac')" "cation-type, 'provider-dhcp-slaac')" {
                          description
                            "Only applies when addresses are
                             allocated by DHCP.";
                        }
                        leaf provider-address {
                          type inet:ipv6-address;
                          description
                            "Address of the provider side.

                             If provider-address is not specified,
                             then prefix length should not be
                             specified either.  It also implies
                             provider-dhcp allocation is not
                             enabled.

                             If provider-address is
                             specified, then prefix length may
                             or may not be specified.";

                        }
                        leaf prefix-length {
                          type uint8 {
                            range "0..128";
                          }
                          must '(../provider-address)' {
                            error-message
                              "If prefix length is specified,
                               provider-address
                               must also be specified.";
                            description
                              "If prefix length is specified,
                                provider-address
                               must also be specified.";
                          }
                          description
                            "Subnet prefix length expressed in
                             bits.

                             If not specified, or specified as
                             zero, this means the customer leaves
                             the actual prefix length value to
                             the provider.";
                        }
                        choice address-assign {
                          default "number";
                          case number {
                            leaf number-of-dynamic-address {
                              type uint16;
                              default "1";
                              description
                                "Describes the number of IP
                                 addresses required by the customer
                   requires.";
                                 customer.";
                            }
                          }
                          case explicit {
                            container customer-addresses {
                              list address-group {
                                key "group-id";
                                leaf group-id {
                                  type string;
                                  description
                                    "Group-id for the address range
                                     from start-address to
                                     end-address.";
                                }
                                leaf start-address {
                                  type inet:ipv6-address;
                                  description
                                    "First address.";
                                }
                                leaf end-address {
                                  type inet:ipv6-address;
                                  description
                                    "Last address.";
                                }
                                description
                                  "Describes IP addresses allocated
                                   by DHCP.

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

                                   When both start-addressand 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.";
                              }
                              description
                                "Container for customer addresses
                                 allocated by DHCP.";
                            }
                          }
                          description
                            "Choice for the way to assign addresses.";
                        }
                        description
                          "DHCP allocated addresses related
                           parameters.";
                      }
        container
                      case dhcp-relay {
                        when "derived-from-or-self(../address-allocation-type, " "derived-from-or-self(./address-allo"
                           + "'l3vpn-svc:provider-dhcp-relay')" "cation-type, 'provider-dhcp-relay')" {
                          description
                            "Only applies when the provider is required
                             to implement DHCP relay function.";
                        }
                        leaf provider-address dr-provider-address {
                          type inet:ipv6-address;
                          description
                            "Address of the provider side.

                             If provider-address is not specified,
                             then prefix length should not be
                             specified either.  It also implies
                             provider-dhcp allocation is not enabled.

                             If provider address is specified, then
                             prefix length may or may not be
                             specified.";
                        }
                        leaf prefix-length dr-prefix-length {
                          type uint8 {
                            range "0..128";
                          }
                          must '(../provider-address)' '(../dr-provider-address)' {
                            error-message
                              "If prefix length is specified,
                               provider-address must also be
                               specified.";
                            description
                              "If prefix length is specified,
                               provider-address must also be
                               specified.";
                          }
                          description
                            "Subnet prefix length expressed in bits.

                             If not specified, or specified as zero,
                             this means the customer leaves the
                             actual prefix length value to the
                             provider.";
                        }
                        container customer-dhcp-servers {
                          leaf-list server-ip-address {
                            type inet:ipv6-address;
                            description
                              "This node contains the IP address of
                               the customer DHCP server.  If the DHCP
                               relay function is implemented by the
                               provider, this node contains the
                               configured value.";
                          }
                          description
                            "Container for list of customer DHCP
                             servers.";
                        }
                        description
                          "DHCP relay provided by operator.";
                      }
        container
                      case static-addresses {
                        when "derived-from-or-self(../address-allocation-type, " "derived-from-or-self(./address-allocation"
                           + "'l3vpn-svc:static-address')" "-type, 'static-address')" {
                          description
                            "Only applies when protocol allocation type
                             is static.";
                        }
                        leaf primary-address s-primary-address {
                          type leafref {
              path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/"
                 + "vpn-node/vpn-network-accesses/vpn-network-access/"
                 + "ip-connection/ipv6/static-addresses/address/"
                 + "address-id";
                            path "../s-address/address-id";
                          }
                          description
                            "Principal address of the connection";
                        }
                        list address s-address {
                          key "address-id";
                          leaf address-id {
                            type string;
                            description
                              "IPv4 Address";
                          }
                          leaf provider-address {
                            type inet:ipv6-address;
                            description
                              "IPv6 Address of the provider side.  When
                               the protocol allocation type is static,
                               the provider address must be
                               configured.";
                          }
                          leaf customer-address {
                            type inet:ipv6-address;
                            description
                              "The IPv6 Address of the customer side.";
                          }
                          leaf prefix-length {
                            type uint8 {
                              range "0..128";
                            }
                            description
                              "Subnet prefix length expressed in bits.
                               It is applied to both provider-address
                               and customer-address.";
                          }
                          description
                            "Describes IPv6 addresses used.";
                        }
                        description
                          "IPv6-specific parameters.";
                      }
                      description
                        "IPv6 allocation type.";
                    }
                    description
                      "IPv6-specific parameters.";
                  }
                  container oam {
                    container bfd {
                      if-feature "l3vpn-svc:bfd"; "vpn-common:bfd";
                      leaf enabled {
                        type boolean;
                        default "false";
                        description
                          "If true, BFD activation is required.";
                      }
                      choice holdtime {
                        default "fixed";
                        case fixed {
                          leaf fixed-value {
                            type uint32;
                            units "msec";
                            description
                              "Expected BFD holdtime expressed in msec. 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 {
                          leaf profile-name {
                            type leafref {
                              path "/l3vpn-ntw/vpn-profiles/"
                                 + "valid-provider-identifiers/"
                                 + "bfd-profile-identifier/id";
                            }
                            description
                              "Well-known SP profile name.

                               The provider can propose some profiles
                               to the customer, depending on the
                               service level the customer wants to
                               achieve.

                               Profile names must be communicated to
                               the customer.";
                          }
                          description
                            "Well-known SP profile.";
                        }
                        description
                          "Choice for holdtime flavor.";
                      }
                      description
                        "Container for BFD.";
                    }
                    description
                      "Defines the Operations, Administration,
                       and Maintenance (OAM)
           mechanisms (OAM)mechanisms used on
                       the connection.

                       BFD is set as a fault detection mechanism,
                       but the 'oam' container can easily
                       be augmented by other mechanisms";
                  }
                  description
                    "Defines connection parameters.";
                }
    description
      "This grouping defines IP connection parameters.";
  }

  grouping site-service-multicast
                container security {
                  container multicast encryption {
                    if-feature "l3vpn-svc:multicast"; "vpn-common:encryption";
                    leaf site-type enabled {
                      type enumeration boolean;
                      default "false";
                      description
                        "If true, traffic encryption on the
                         connection is required. It is
                         disabled, otherwise.";
                    }
                    leaf layer {
          enum receiver-only
                      when "../enabled = 'true'" {
                        description
              "The site only has receivers.";
                          "Require a value for layer when
                           enabled is true.";
                      }
                      type enumeration {
                        enum source-only layer2 {
                          description
              "The site only has sources.";
                            "Encryption will occur at Layer 2.";
                        }
                        enum source-receiver layer3 {
                          description
              "The site has both sources and receivers.";
                            "Encryption will occur at Layer 3.
                             For example, IPsec may be used when
                             a customer requests Layer 3
                             encryption.";
                        }
                      }
        default "source-receiver";
                      description
          "Type of multicast site.";
                        "Layer on which encryption is applied.";
                    }
                    description
                      "Container for CE-PE security encryption.";
                  }
                  container address-family encryption-profile {
        leaf ipv4
                    choice profile {
          if-feature "l3vpn-svc:ipv4";
          type boolean;
          default "false";
          description
            "Enables IPv4 multicast.";
        }
        leaf ipv6
                      case provider-profile {
          if-feature "l3vpn-svc:ipv6";
          type boolean;
          default "false";
          description
            "Enables IPv6 multicast.";
        }
        description
          "Defines protocol to carry multicast.";
      }
                        leaf protocol-type profile-name {
                          type enumeration {
          enum host leafref {
            description
              "Hosts are directly connected to the provider network.
               Host protocols such as IGMP or MLD are required.";
                            path "/l3vpn-ntw/vpn-profiles"
                               + "/valid-provider-identifiers"
                               + "/encryption-profile-identifier/id";
                          }
          enum router {
                          description
              "Hosts are behind a customer router.
               PIM will
                            "Name of the SP profile to be implemented."; applied.";
                        }
          enum both
                      }
                      case customer-profile {
                        leaf algorithm {
                          type string;
                          description
              "Some hosts are behind a customer router, and
               some others are directly connected
                            "Encryption algorithm to the
               provider network.  Both host and routing protocols
               must be used.  Typically, IGMP and PIM will be
               implemented."; used.";
                        }
                      }
        default "both";
                      description
          "Multicast protocol type to be used with the customer site.";
                        "Choice for encryption profile.";
                    }
                    choice key-type {
                      default "psk";
                      case psk {
                        leaf remote-source preshared-key {
                          type boolean;
        default "false"; string;
                          description
          "When true, there is no PIM adjacency on
                            "Pre-Shared Key (PSK) coming from the interface.";
                             customer.";
                        }

                      }
                      description
        "Multicast parameters for
                        "Choice of encryption profile.
                         The encryption profile can be the site.";
                         provider profile or customer profile.";
                    }
                    description
      "Multicast parameters
                      "Container for the site."; encryption profile.";
                  }
                  description
                    "Site-specific security parameters.";
                }

  grouping site-maximum-routes {
                container maximum-routes routing-protocols {
                  list address-family routing-protocol {
                    key "af"; "id";
                    leaf af id {
                      type l3vpn-svc:address-family; string;
                      description
            "Address family.";
                        "Unique identifier for routing protocol.";
                    }
                    leaf maximum-routes type {
                      type uint32;
          description
            "Maximum prefixes the VRF can accept
             for this address family."; identityref {
                        base vpn-common:routing-protocol-type;
                      }
                      description
          "List
                        "Type of address families."; routing protocol.";
                    }
      description
        "Defines 'maximum-routes' for the VRF.";
                    list routing-profiles {
                      key "id";
                      leaf id {
                        type leafref {
                          path "/l3vpn-ntw/vpn-profiles"
                             + "/valid-provider-identifiers"
                             + "/routing-profile-identifier/id";
                        }
                        description
      "Defines 'maximum-routes' for the site.";
                          "Routing profile to be used.";
                      }
  grouping site-security
                      leaf type {
    container security
                        type identityref {
      uses site-security-authentication;
      uses site-security-encryption;
                          base vpn-common:ie-type;
                        }
                        description
        "Site-specific security parameters.";
                          "Import, export or both.";
                      }
                      description
      "Grouping for security parameters.";
                        "Routing profiles.";
                    }

  grouping network-access-service {
                    container service ospf {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:ospf')" {
      uses site-service-basic;
      /* Extension */
      /* uses svc-bandwidth-params; */
      /* EoExt */
      uses site-service-qos-profile;
      uses site-service-mpls;
      uses site-service-multicast;
                        description
        "Service parameters
                          "Only applies when protocol is OSPF.";
                      }
                      if-feature "vpn-common:rtg-ospf";
                      leaf-list address-family {
                        type vpn-common:address-family;
                        min-elements 1;
                        description
                          "If OSPF is used on this site, this node
                           contains a configured value.  This node
                           contains at least one address family
                           to be activated.";
                      }
                      leaf area-address {
                        type yang:dotted-quad;
                        mandatory true;
                        description
                          "Area address.";
                      }
                      leaf metric {
                        type uint16;
                        default "1";
                        description
                          "Metric of the attachment."; PE-CE link.  It is used
                           in the routing state calculation and
                           path selection.";
                      }
                      leaf mtu {
                        type uint16;
                        description
      "Grouping
                          "Maximum transmission unit for service parameters."; a given
                           OSPF link.";
                      }

  grouping vpn-extranet
                      leaf process-id {
                        type uint16;
                        description
                          "Process id of the OSPF CE-PE connection.";
                      }
                      uses security-params;
                      container extranet-vpns sham-links {
                        if-feature "l3vpn-svc:extranet-vpn"; "vpn-common:rtg-ospf-sham-link";
                        list extranet-vpn sham-link {
                          key "vpn-id"; "target-site";
                          leaf vpn-id target-site {
                            type l3vpn-svc:svc-id; vpn-common:vpn-id;
                            description
            "Identifies the target VPN
                              "Target site for the local VPN want sham link connection.
                               The site is referred to access."; by its ID.";
                          }
                          leaf local-sites-role metric {
                            type identityref {
            base l3vpn-svc:site-role;
          } uint16;
                            default "l3vpn-svc:any-to-any-role"; "1";
                            description
          "This describes the role
                              "Metric of the
           local sites sham link.  It is used in
                               the target VPN topology.
           In the any-to-any VPN service topology,
           the local sites must have the same role, which
           will be 'any-to-any-role'.  In the Hub-and-Spoke
           VPN service topology or the Hub-and-Spoke
           disjoint VPN service topology,
           the local sites must have a Hub role or routing state calculation and path
                               selection.  The default value is set
                               to 1.";
                          }
                          description
                            "Creates a Spoke role."; sham link with another site.";
                        }
                        description
                          "List of extranet VPNs or target VPNs the local VPN is
           attached to."; sham links.";
                      }
                      description
        "Container for extranet VPN
                        "OSPF-specific configuration.";
                    }
    description
      "Grouping for extranet VPN configuration.
       This provides an easy way to interconnect
       all sites from two VPNs.";
  }

  grouping vpn-profile-cfg {
                    container valid-provider-identifiers bgp {
      list cloud-identifier
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:bgp')" {
                        description
                          "Only applies when protocol is BGP.";
                      }
                      if-feature "l3vpn-svc:cloud-access";
        key "id"; "vpn-common:rtg-bgp";
                      leaf id peer-autonomous-system {
                        type string;
          description
            "Identification of cloud service.
             Local administration meaning.";
        } inet:as-number;
                        mandatory true;
                        description
          "List for Cloud Identifiers.";
                          "Indicates the Customer's AS Number (ASN) in
                           case the Customer requests BGP routing.";
                      }
      list encryption-profile-identifier {
        key "id";
                      leaf id local-autonomous-system {
                        type string; inet:as-number;
                        description
            "Identification of
                          "Is set to the SP encryption profile ASN to override a peers' ASN
                           if such feature is requested by the
                           Customer.";
                      }
                      leaf-list address-family {
                        type vpn-common:address-family;
                        min-elements 1;
                        description
                          "This node contains at least one
                           address-family to be used.  Local administration meaning.";
        }
        description
          "List for encryption profile identifiers."; activated.";
                      }
      list qos-profile-identifier {
        key "id";
        leaf id
                      leaf-list neighbor {
                        type string; inet:ip-address;
                        description
            "Identification
                          "IP address(es) of the QoS Profile to BGP neighbor. IPv4
                           and IPv6 neighbors may be used.

             Local administration meaning.";
        }
        description
          "List indicated if
                           two sessions will be used for QoS Profile Identifiers."; IPv4 and
                           IPv6.";
                      }
      list bfd-profile-identifier {
        key "id";
                      leaf id multihop {
                        type string; uint8;
                        description
            "Identification
                          "Describes the number of IP hops allowed
                           between a given BGP neighbor and the SP BFD Profile to be used.
             Local administration meaning.";
        }
        description
          "List for BFD Profile identifiers."; PE.";
                      }
      list routing-profile-identifier {
        key "id";
                      uses security-params;
                      uses vpn-common:service-status;
                      leaf id description {
                        type string;
                        description
            "Identification
                          "Includes a description of the routing Profile BGP session.
                           Such description is meant to be used
             by the routing-protocols within sites, vpn-
             network-accesses or vpn-nodes for refering
       vrf-import/export policies.
             This identifier has a local meaning.";
        }
        description
          "List for Routing Profile Identifiers.";
      }
      nacm:default-deny-write;
      description
        "Container for Valid Provider Identifies.";
    }
                           diagnosis purposes. The semantic of the
                           description
      "Grouping for VPN Profile configuration."; is local to an
                           implementation.";
                      }

  grouping vpn-svc-cfg {
                      leaf vpn-id as-override {
                        type l3vpn-svc:svc-id; boolean;
                        default "false";
                        description
        "VPN identifier.
    This identifier has a
                          "Defines whether AS override is enabled,
                           i.e., replace the ASN of the peer specified
                           in the AS Path attribute with the local meaning.";
                           AS number.";
                      }
                      leaf l3sm-vpn-id default-route {
                        type l3vpn-svc:svc-id; boolean;
                        default "false";
                        description
        "Pointer
                          "Defines whether default route(s) can be
                           advertised to its peer. If set, the L3SM service.";
                           default route(s) is advertised to its
                           peer.";
                      }
                      container bgp-max-prefix {
                        leaf customer-name max-prefix {
                          type string; uint32;
                          default "5000";
                          description
      "Name of the customer that actually uses the VPN service.
       In the case that any intermediary (e.g., Tier-2 provider
       or partner) sells
                            "Indicates the VPN service to their end user
       on behalf maximimum number of BGP
                             prefixes allowed in the original service provider (e.g., Tier-1
       provider), the original service provider may require the
       customer name BGP session.

                             It allows to provide smooth activation/commissioning
       and operation for control how many prefixes
                             can be received from a neighbor.

                             If the limit is exceeded, the service."; session
                              can be teared down.";
                          reference
                            "RFC4271, Section 8.2.2.";
                        }
                        leaf vpn-service-topology warning-threshold {
                          type identityref decimal64 {
        base vpn-topology;
                            fraction-digits 5;
                            range "0..100";
                          }
                          units "percent";
                          default "any-to-any"; "75";
                          description
        "VPN service topology.";
                            "When this value is reached, a warning
                             notification will be triggered.";
                        }
                        leaf violate-action {
                          type enumeration {
                            enum warning {
                              description
                                "Only a warning message is sent to
                                 the peer when the limit is
                                 exceeded.";
                            }
                            enum discard-extra-paths {
                              description
                                "Discards extra paths when the
                                 limit is exceeded.";
                            }
                            enum restart {
                              description
                                "Restart after a time interval.";
                            }
                          }
                          description
                            "BGP neighbour max-prefix violate
                             action";
                        }
                        leaf restart-interval {
                          type string; uint16;
                          units "minutes";
                          description
        "Textual
                            "Time interval (min) after which the
                             BGP session will be reestablished.";
                        }
                        description of
                          "Controls the behavior when a VPN service."; prefix
                           maximum is reached.";
                      }
    uses ie-profiles-params;
    uses svc-transport-encapsulation;
    uses vpn-nodes-params;
    /* uses vpn-service-multicast; */
    /* uses vpn-service-mpls; */
    /* uses vpn-extranet;*/
                      container bgp-timer {
                        description
      "Grouping for
                          "Includes two BGP timers that can be
                           customized when building a VPN service configuration.";
  }

  grouping site-network-access-top-level-cfg {
    uses status-params;
                           with BGP used as CE-PE routing
                           protocol.";
                        leaf vpn-network-access-type keep-alive {
                          type identityref uint16 {
        base l3vpn-svc:site-network-access-type;
                            range "0..21845";
                          }
                          units "seconds";
                          default "l3vpn-svc:point-to-point"; "30";
                          description
        "Describes
                            "This timer indicates the KEEPALIVE
                             messages'  frequency between a PE
                             and a BGP peer.

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

                             It is suggested that the maximum time
                             between  KEEPALIVEmessages would be
                             one third of the Hold Time interval.";
                          reference
                            "Section 4.4 of RFC 4271";
                        }
                        leaf hold-time {
                          type uint16 {
                            range "0 | 3..65535";
                          }
                          units "seconds";
                          default "90";
                          description
                            "It indicates the maximum number of connection, e.g.,
         point-to-point
                            seconds that may elapse between the
                            receipt of successive KEEPALIVE
                            and/or UPDATE   messages from the peer.

                            The Hold Time must be either zero or multipoint.";
                            at least three seconds.";
                          reference
                            "Section 4.2 of RFC 4271";
                        }
                      }
    uses ethernet-params;
    uses site-attachment-ip-connection;
    uses site-security;
    uses site-routing;
    uses network-access-service;
                      description
      "Grouping for site network access top-level
                        "BGP-specific configuration.";
                    }

  /* Bearers in a site */

  grouping site-bearer-params {
                    container site-bearers isis {
      list bearer
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:isis')" {
        key "bearer-id";
                        description
                          "Only applies when protocol is IS-IS.";
                      }
                      if-feature "vpn-common:rtg-isis";
                      leaf-list address-family {
                        type vpn-common:address-family;
                        min-elements 1;
                        description
                          "If ISIS is used on this site, this node
                           contains a configured value.  This node
                           contains at least one address family
                           to be activated.";
                      }
                      leaf bearer-id area-address {
                        type string; yang:dotted-quad;
                        mandatory true;
                        description
            "";
                          "Area address.";
                      }
                      leaf BearerType level {
                        type identityref {
                          base bearer-inf-type; isis-level;
                        }
                        description
            "Request for an Bearer access type.
             Choose between port
                          "level1, level2 or lag connection type."; level1-2";
                      }
                      leaf ne-id metric {
                        type string; uint16;
                        default "1";
                        description
            "NE-id reference.";
                          "Metric of the PE-CE link.  It is used
                           in the routing state calculation and
                           path selection.";
                      }
                      leaf port-id process-id {
                        type string; uint16;
                        description
            "Reference to the Port-id.
             The semantic
                          "Process id of the Port-Id depends on the vendor's
             semantic. i.e ge-X/Y/Z , xe-X/Y/Z , et-X/Y/Z,AeXXX.YYY,
             aeXXX,GigabitEthernetX/Y/Z"; IS-IS CE-PE
                           connection.";
                      }
                      leaf lag-id mode {
                        type string; enumeration {
                          enum active {
                            description
            "lag-id in format id.";
                              "Interface sends or receives IS-IS
                               protocol control packets.";
                          }
                          enum passive {
                            description
          "Parameters used to identify each bearer";
                              "Suppresses the sending of IS-IS
                               updates through the specified
                               interface.";
                          }
                        }
                        default "active";
                        description
        "Grouping to reuse the site bearer assigment";
                          "IS-IS interface mode type.";
                      }
                      uses vpn-common:service-status;
                      description
      "Grouping
                        "IS-IS specific configuration.";
                    }
                    container static {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:static')" {
                        description
                          "Only applies when protocol is static.
                           BGP activation requires the SP to reuse know
                           the site bearer assigment"; address of the customer peer.  When
                           BGP is enabled, the 'static-address'
                           allocation type for the IP connection
                           must be used.";
                      }

  /* UNUSED */

  grouping svc-bandwidth-params {
                      container svc-bandwidth cascaded-lan-prefixes {
      if-feature "input-bw";
                        list bandwidth ipv4-lan-prefixes {
                          if-feature "vpn-common:ipv4";
                          key "direction type"; "lan next-hop";
                          leaf direction lan {
                            type identityref {
            base bw-direction; inet:ipv4-prefix;
                            description
                              "LAN prefixes.";
                          }
                          leaf lan-tag {
                            type string;
                            description
            "Indicates the bandwidth direction.  It can
                              "Internal tag to be
             the bandwidth download direction from the SP used in VPN
                               policies.";
                          }
                          leaf next-hop {
                            type inet:ipv4-address;
                            description
                              "Next-hop address to use on the site or the bandwidth upload direction from
                               customer side.";
                          }
                          description
                            "List of LAN prefixes for the site site.";
                        }
                        list ipv6-lan-prefixes {
                          if-feature "vpn-common:ipv6";
                          key "lan next-hop";
                          leaf lan {
                            type inet:ipv6-prefix;
                            description
                              "LAN prefixes.";
                          }
                          leaf lan-tag {
                            type string;
                            description
                              "Internal tag to the SP."; be used in VPN
                               policies.";
                          }
                          leaf type next-hop {
                            type identityref {
            base bw-type; inet:ipv6-address;
                            description
                              "Next-hop address to use on the
                               customer side.";
                          }
                          description
            "Bandwidth type.  By default,
                            "List of LAN prefixes for the bandwidth type
             is set site.";
                        }
                        description
                          "LAN prefixes from the customer.";
                      }
                      description
                        "Configuration specific to 'bw-per-cos'."; static routing.";
                    }
        leaf cos-id
                    container rip {
                      when "derived-from-or-self(../type, "
                         + "'l3vpn-ntw:bw-per-cos')" "'vpn-common:rip')" {
                        description
              "Relevant
                          "Only applies when the bandwidth type protocol is set to
               'bw-per-cos'."; RIP.
                           For IPv4, the model assumes that RIP
                           version 2 is used.";

                      }
                      if-feature "vpn-common:rtg-rip";
                      leaf-list address-family {
                        type uint8; vpn-common:address-family;
                        min-elements 1;
                        description
            "Identifier of the CoS, indicated by DSCP or a
             CE-VLAN CoS (802.1p) value in the service frame.
             If the bandwidth type
                          "If RIP is set used on this site, this node
                           contains a configured value.  This node
                           contains at least one address family
                           to 'bw-per-cos',
             the CoS ID MUST also be specified."; activated.";
                      }
        leaf vpn-id
                      description
                        "Configuration specific to RIP routing.";
                    }
                    container vrrp {
                      when "derived-from-or-self(../type, "
                         + "'l3vpn-ntw:bw-per-svc')" "'vpn-common:vrrp')" {
                        description
              "Relevant
                          "Only applies when the bandwidth type protocol is
               set as bandwidth per VPN service."; VRRP.";
                      }
                      if-feature "vpn-common:rtg-vrrp";
                      leaf-list address-family {
                        type l3vpn-svc:svc-id; vpn-common:address-family;
                        min-elements 1;
                        description
            "Identifies the target VPN.  If the bandwidth
             type
                          "If VRRP is set as bandwidth per VPN service, the
             vpn-id MUST used on this site, this node
                           contains a configured value.  This node
                           contains at least one address family to
                           be specified."; activated.";
                      }
                      leaf cir vrrp-group {
                        type uint64;
          units "bps";
          mandatory true; uint8 {
                          range "1..255";
                        }
                        description
            "Committed Information Rate.  The maximum number
             of bits that a port can receive or send over
             an interface in one second.";
                          "VRRP group number";
                      }
                      leaf cbs backup-peer {
                        type uint64;
          units "bps";
          mandatory true; inet:ip-address;
                        description
            "Committed Burst Size (CBS).  Controls the bursty
             nature
                          "IP address of the traffic.  Traffic that does not
             use the configured Committed Information Rate
             (CIR) accumulates credits until the credits
             reach the configured CBS."; peer";
                      }
                      leaf eir priority {
                        type uint64;
          units "bps"; uint8;
                        description
            "Excess Information Rate (EIR), i.e., excess frame
             delivery allowed that is not subject to an SLA.
             The traffic rate can be limited by
                          "Local priority of the EIR."; VRRP speaker";
                      }
                      leaf ebs ping-reply {
                        type uint64;
          units "bps"; boolean;
                        description
            "Excess Burst Size (EBS).  The bandwidth available
             for burst traffic from
                          "Whether the EBS is subject VRRP speaker should answer
                           to the
             amount ping requests";
                      }
                      description
                        "Configuration specific to VRRP.";
                    }
                    description
                      "List of bandwidth that is accumulated during
             periods when traffic allocated by routing protocols used on
                       the EIR
             policy is not used."; site.  This list can be augmented.";
                  }
                  description
                    "Defines routing protocols.";
                }
                container service {
                  leaf pir svc-input-bandwidth {
                    type uint64;
                    units "bps";
                    mandatory true;
                    description
            "Peak Information Rate, i.e., maximum frame
             delivery allowed.  It is equal to or less
             than
                      "From the customer site's perspective, the sum
                       service input bandwidth of the CIR and connection
                       or download bandwidth from the SP to
                       the EIR."; site.";
                  }
                  leaf pbs svc-output-bandwidth {
                    type uint64;
                    units "bps";
          description
            "Peak Burst Size.  It is measured in bytes per
             second.";
        }
        description
          "List of bandwidth values (e.g., per CoS,
           per vpn-id).";
      }
                    mandatory true;
                    description
                      "From the customer site's perspective,
                       the service
         input/output output bandwidth of the
                       connection or
         download/upload upload bandwidth from
                       the SP/site site to the site/SP."; SP.";
                  }
                  leaf svc-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 'svc-mtu' leaf will refer
                        to the MPLS MTU and not to the IP MTU.";
                  }

  grouping status-params
                  container qos {
                    if-feature "vpn-common:qos";
                    container status qos-classification-policy {
                      list rule {
                        key "id";
                        ordered-by user;
                        leaf admin-enabled id {
                          type boolean; string;
                          description
          "Administrative Status UP/DOWN";
                            "A description identifying the
                             qos-classification-policy rule.";
                        }
      leaf oper-status
                        choice match-type {
        type operational-type;
        config false;
                          default "match-flow";
                          case match-flow {
                            choice l3 {
                              container ipv4 {
                                uses pf:acl-ip-header-fields;
                                uses pf:acl-ipv4-header-fields;
                                description
          "Operations status";
                                  "Rule set that matches IPv4 header.";
                              }
                              container ipv6 {
                                uses pf:acl-ip-header-fields;
                                uses pf:acl-ipv6-header-fields;
                                description
        "Container for status parameters.";
                                  "Rule set that matches IPv6 header.";
                              }
                              description
      "Grouping used to join operational and administrative status
       is re used in the Site Network Acess and in the VPN-Node";
                                "Either IPv4 or IPv6.";
                            }

  /* Parameters related to vpn-nodes (VRF config.) */

  grouping vpn-nodes-params
                            choice l4 {
                              container tcp {
                                uses pf:acl-tcp-header-fields;
                                uses ports;
                                description
                                  "Rule set that matches TCP header.";
                              }
                              container vpn-nodes udp {
                                uses pf:acl-udp-header-fields;
                                uses ports;
                                description
        "Container for VPN nodes.";
      list vpn-node {
        key "ne-id";
        leaf vpn-node-id {
          type union {
            type l3vpn-svc:svc-id;
            type uint32;
                                  "Rule set that matches UDP header.";
                              }
                              description
            "Type STRING
                                "Can be TCP or NUMBER Serivice-Id"; UDP";
                            }
                          }
                          case match-application {
                            leaf local-autonomous-system match-application {
                              type inet:as-number; identityref {
                                base vpn-common:customer-application;
                              }
                              description
            "Provider AS number in case
                                "Defines the customer
             requests BGP routing."; application to match.";
                            }
                          }
        leaf
                          description
                            "Choice for classification.";
                        }
                        leaf target-class-id {
                          type string;
                          description
            "Textual description
                            "Identification of the VPN node."; class of service.
                             This identifier is internal to the
                             administration.";
                        }
        leaf ne-id {
          type string;
                        description
            "Unique identifier
                          "List of marking rules.";
                      }
                      description
                        "Configuration of the network element
      where the vpn-node is deployed."; traffic classification
                         policy.";
                    }
        leaf router-id
                    container qos-profile {
          type inet:ip-address;
                      list qos-profile {
                        key "profile";
                        description
            "router-id information can
                          "QoS profile.
                           Can be ipv4/6 addresses";
        } standard profile or customized
                           profile.";
                        leaf address-family profile {
                          type l3vpn-svc:address-family; leafref {
                            path "/l3vpn-ntw/vpn-profiles"
                               + "/valid-provider-identifiers"
                               + "/qos-profile-identifier/id";
                          }
                          description
            "Address family used for router-id information.";
                            "QoS profile to be used.";
                        }
                        leaf node-role direction {
                          type identityref {
                            base l3vpn-svc:site-role; vpn-common:qos-profile-direction;
                          }
                          default "l3vpn-svc:any-to-any-role"; "vpn-common:both";
                          description
            "Role of the vpn-node in
                            "The direction to which the IP VPN."; QoS profile
                             is applied.";

                        }
        uses rt-rd;
        uses status-params;
        uses net-acc;
        uses site-maximum-routes;
        uses vpn-service-multicast;
                      }
                      description
                        "QoS profile configuration.";
                    }
                    description
                      "QoS configuration.";
                  }
                  container carrierscarrier {
                    if-feature "vpn-common:carrierscarrier";
                    leaf node-ie-profile signalling-type {
                      type leafref enumeration {
            path "/l3vpn-ntw/vpn-services/"
               + "vpn-service/ie-profiles/ie-profile/ie-profile-id";
                        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";
                        }
          description
            "node Import/Export profile.";
                      }
                      default "bgp";
                      description
          "List for VPN node.";
      }
                        "MPLS signalling type.";
                    }
                    description
      "Grouping
                      "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 define VRF-specific configuration."; carry its traffic).";
                  }

  /* Parameters related to import and export profiles (RTs RDs.) */

  grouping ie-profiles-params {
                  container ie-profiles {
      list ie-profile multicast {
        key "ie-profile-id";
                    if-feature "vpn-common:multicast";
                    leaf ie-profile-id site-type {
                      type string;
          description
            "IE profile id.";
        }
        uses rt-rd; enumeration {
                        enum receiver-only {
                          description
          "List for Imort/Export profile.";
                            "The site only has receivers.";

                        }
                        enum source-only {
                          description
        "Container for Import/Export profiles.";
                            "The site only has sources.";
                        }
                        enum source-receiver {
                          description
      "Grouping to specify rules for route import
                            "The site has both sources and export";
                             receivers.";
                        }
  grouping pseudowire-params {
    container pseudowire {
      /*leaf far-end {*/
      /*
                      }
                      default "source-receiver";
                      description "IP of the remote peer
                        "Type of the pseudowire.";*/
      /*  type inet:ip-address;*/
      /*}*/ multicast site.";
                    }
                    leaf vcid address-family {
                      type uint32; vpn-common:address-family;
                      description
          "PW or VC identifier.";
                        "Address family.";
                    }
                    leaf far-end protocol-type {
                      type union enumeration {
                        enum host {
          type uint32;
          type inet:ipv4-address;
        }
        description
          "SDP/Far End/LDP Neighbour reference.";
      }
                          description
        "Pseudowire termination parameters";
                            "Hosts are directly connected to the
                             provider network.

                             Host protocols such as IGMP or MLD are
                             required.";
                        }
    container vpls {
      leaf vcid {
        type union
                        enum router {
          type uint32;
          type string;
        }
                          description
          "VCID identifier,IRB/RVPPLs interface
           supported using string
           format.";
                            "Hosts are behind a customer router.
                             PIM will be implemented.";
                        }
      leaf far-end {
        type union
                        enum both {
          type uint32;
          type inet:ipv4-address;
        }
                          description
          "SDP/Far End/LDP Neighbour reference.";
                            "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.";
                        }
      description
        "Pseudowire termination parameters";
                      }
                      default "both";
                      description
      "Grouping pseudowire termination parameters";
                        "Multicast protocol type to be used with
                         the customer site.";
                    }
  grouping security-params {
    container security {
                    leaf auth-key remote-source {
                      type string; boolean;
                      default "false";
                      description
          "MD5 authentication password
                        "When true, there is no PIM adjacency on
                         the interface.";
                    }
                    description
                      "Multicast parameters for the connection towards site.";
                  }
                  description
                    "Service parameters on the
           customer edge."; attachment.";
                }
                description
        "Container for aggregating any security parameter
                  "List of accesses for routing
         sessions between a PE and a CE."; site.";
              }
              description
      "Grouping to define security parameters";
                "List of accesses for a site.";
            }

  grouping ethernet-params {
            container connection maximum-routes {
              list address-family {
                key "af";
                leaf encapsulation-type af {
                  type identityref {
          base encapsulation-type;
        }
        default "untagged-int"; vpn-common:address-family;
                  description
          "Encapsulation type.  By default,
                    "Indicates the
           encapsulation type is set to 'untagged'."; address family
                    (IPv4 or IPv6).";
                }
      container logical-interface {
                leaf peer-reference maximum-routes {
                  type uint32;
                  description
            "Specify
                    "Indicates the associated logical peer
      interface"; maximum prefixes the VRF
                     can accept for this address family.";
                }
                description
          "Reference
                  "List of a logical interface type.";
      }
      container tagged-interface {
        leaf type {
          type identityref {
            base tagged-inf-type; address families.";
              }
          default "priority-tagged";
              description
            "Tagged interface type.  By default,
             the type of
                "Defines 'maximum-routes' for the tagged interface is
             'priority-tagged'."; VRF.";
            }
            container dot1q-vlan-tagged {
          when "derived-from-or-self(../type, "
             + "'l3vpn-ntw:dot1q')" multicast {
            description
              "Only applies when the type of the tagged
               interface is 'dot1q'.";
          }
              if-feature "dot1q"; "vpn-common:multicast";
              leaf tag-type enabled {
                type identityref {
              base tag-type;
            } boolean;
                default "c-vlan";
            description
              "Tag type.  By default, the tag type is
               'c-vlan'.";
          }
          leaf cvlan-id {
            type uint16;
            description
              "VLAN identifier.";
          }
          description
            "Tagged interface.";
        }
        container priority-tagged {
          when "derived-from-or-self(../type, "
             + "'l3vpn-ntw:priority-tagged')" {
            description
              "Only applies when the type of the tagged
               interface is 'priority-tagged'."; "false";
                description
                  "Enables multicast.";
              }
          leaf tag-type
              leaf-list tree-flavor {
                type identityref {
                  base tag-type;
            }
            default "c-vlan";
            description
              "Tag type.  By default, the tag type is
               'c-vlan'."; vpn-common:multicast-tree-type;
                }
                description
            "Priority tagged.";
                  "Type of tree to be used.";
              }
              container qinq rp {
          when "derived-from-or-self(../type, "
             + "'l3vpn-ntw:qinq')"
                container rp-group-mappings {
                  list rp-group-mapping {
                    key "id";
                    leaf id {
            description
              "Only applies when the
                      type of uint16;
                      description
                        "Unique identifier for the tagged
               interface is 'qinq'."; mapping.";
                    }
          if-feature "qinq";
                    container provider-managed {
                      leaf tag-type enabled {
                        type identityref {
              base tag-type;
            } boolean;
                        default "c-s-vlan"; "false";
                        description
              "Tag type.  By default,
                          "Set to true if the tag type Rendezvous Point (RP)
                           must be a provider-managed node.  Set to
                           false if it is
               'c-s-vlan'."; a customer-managed node.";
                      }
                      leaf svlan-id rp-redundancy {
                        type uint16;
            mandatory true; boolean;
                        default "false";
                        description
              "SVLAN identifier.";
                          "If true, a redundancy mechanism for the
                           RP is required.";
                      }
                      leaf cvlan-id optimal-traffic-delivery {
                        type uint16;
            mandatory true;
            description
              "CVLAN identifier.";
          } boolean;
                        default "false";
                        description
            "QinQ.";
                          "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.";
                      }
                      container qinany anycast {
                        when "derived-from-or-self(../type, "
             + "'l3vpn-ntw:qinany')" "../rp-redundancy = 'true' and
                              ../optimal-traffic-delivery = 'true'" {
                          description
                            "Only applies when the type of the tagged
               interface applicable if
                             RP redundancy is 'qinany'.";
                             enabled and delivery through
                             optimal path is activated.";
                        }
          if-feature "qinany";
                        leaf tag-type local-address {
                          type identityref {
              base tag-type;
            }
            default "s-vlan"; inet:ip-address;
                          description
              "Tag type.  By default, the tag type is
               's-vlan'.";
                            "IP local address for PIM RP.
                             Usually, it corresponds to router
                             ID or primary address";
                        }
          leaf svlan-id
                        leaf-list rp-set-address {
                          type uint16;
            mandatory true; inet:ip-address;
                          description
              "Service VLAN ID.";
                            "Address other RP routers
                             that share the same RP IP address.";
                        }
                        description
            "Container for QinAny.";
                          "PIM Anycast-RP parameters.";
                      }
        container vxlan
                      description
                        "Parameters for a provider-managed RP.";
                    }
                    leaf rp-address {
                      when "derived-from-or-self(../type, "
             + "'l3vpn-ntw:vxlan')" "../provider-managed/enabled = 'false'" {
                        description
              "Only applies
                          "Relevant when the type of the tagged
               interface RP is 'vxlan'."; not
                           provider-managed.";
                      }
          if-feature "vxlan";
          leaf vni-id {
                      type uint32; inet:ip-address;
                      mandatory true;
                      description
              "VXLAN Network Identifier (VNI).";
          }
          leaf peer-mode {
            type identityref {
              base vxlan-peer-mode;
            }
            default "static-mode";
            description
              "Specifies
                        "Defines the VXLAN access mode.  By default, address of the peer mode RP.
                         Used if the RP is set to 'static-mode'."; customer-managed.";
                    }
                    container groups {
                      list peer-list group {
                        key "peer-ip"; "id";
                        leaf peer-ip id {
                          type inet:ip-address;
              description
                "Peer IP.";
            }
            description
              "List of peer IP addresses.";
          }
          description
            "QinQ.";
        } uint16;
                          description
          "Container
                            "Identifier for tagged interfaces."; the group.";
                        }
      container bearer
                        choice group-format {
                          mandatory true;
                          case group-prefix {
                            leaf bearer-reference group-address {
          if-feature "l3vpn-svc:bearer-reference";
                              type string;
          description
            "This is an internal reference for the SP.";
        }
        uses pseudowire-params;
        description
          "Defines physical properties of a site attachment.";
      } inet:ip-prefix;
                              description
        "Encapsulation types";
                                "A single multicast group prefix.";
                            }
    description
      "Grouping to define encapsulation types";
                          }

  grouping rt-rd
                          case startend {
                            leaf rd {
      type union group-start {
                              type rt-types:route-distinguisher;
      type empty;
    } inet:ip-address;
                              description
       "Route distinguisher value. If this leaf has not been
        configured, the server will auto-assign a route
        distinguisher value and use that value operationally.
        This calculated value is available
                                "The first multicast group address in
                                 the operational
        state. Use the empty type to indicate rd has no value
        and is not to be aouto-assigned";
    }
    container vpn-targets {
      description
        "Set of route-targets to match for import and export routes
         to/from VRF";
      //uses rt-types:vpn-route-targets;
      uses vpn-route-targets;
    }
    description
      "Grouping for RT and RD."; multicast group address range.";
                            }

  grouping vpn-route-targets {
    description
      "A grouping that specifies Route Target import-export rules
       used in a BGP-enabled VPN.";
    list vpn-target {
      key "id";
                            leaf id group-end {
                              type int8; inet:ip-address;
                              description
          "Identifies each VPN Target";
                                "The last multicast group address in
                                 the multicast group address range.";
                            }
                          }
      list route-targets {
        key "route-target";
        leaf route-target {
          type rt-types:route-target;
                          description
            "Route Target value";
                            "Choice for multicast group format.";
                        }
                        description
                          "List of Route Targets."; multicast groups.";
                      }
      leaf route-target-type {
        type rt-types:route-target-type;
        mandatory true;
                      description
          "Import/export type of
                        "Multicast groups associated with the Route Target."; RP.";
                    }
                    description
        "l3vpn route targets. AND/OR Operations are available
         based on the RTs assigment";
                      "List of RP-to-group mappings.";
                  }
                  description
                    "RP-to-group mappings parameters.";
                }
    reference
      "RFC4364: BGP/MPLS IP Virtual Private Networks (VPNs)
       RFC4664: Framework for Layer 2 Virtual Private Networks
       (L2VPNs)";
                container vpn-policies rp-discovery {
      description
        "";
                  leaf import-policy rp-discovery-type {
                    type leafref identityref {
          path "/l3vpn-ntw/vpn-profiles/valid-provider-identifiers/"
             + "routing-profile-identifier/id";
                      base vpn-common:multicast-rp-discovery-type;
                    }
                    default "vpn-common:static-rp";
                    description
          "Reference to a VRF import policy.";
                      "Type of RP discovery used.";
                  }
      leaf export-policy
                  container bsr-candidates {
                    when "derived-from-or-self(../rp-discovery-type, "
                       + "'vpn-common:bsr-rp')" {
                      description
                        "Only applicable if discovery type leafref
                         is BSR-RP.";
                    }
                    leaf-list bsr-candidate-address {
          path "/l3vpn-ntw/vpn-profiles/valid-provider-identifiers/"
             + "routing-profile-identifier/id";
                      type inet:ip-address;
                      description
                        "Address of candidate Bootstrap Router
                        (BSR).";
                    }
                    description
          "Reference to a VRF export policy.";
                      "Container for List of Customer
                       BSR candidate's addresses.";
                  }
                  description
                    "RP discovery parameters.";
                }
                description
                  "RP parameters.";
              }
  grouping net-acc {
              container vpn-network-accesses {
      list vpn-network-access msdp {
        key "id";
                if-feature "msdp";
                leaf id enabled {
                  type l3vpn-svc:svc-id; boolean;
                  default "false";
                  description
            "Identifier for the access.";
                    "If true, MSDP is activated.";
                }
                leaf port-id peer {
                  type l3vpn-svc:svc-id; inet:ip-address;
                  description
            "Identifier for
                    "IP address of the network access."; MSDP peer.";
                }
                leaf description local-address {
                  type string;
          description
            "Textual inet:ip-address;
                  description
                    "IP address of a VPN service."; the local end. This local
                     address must be configured on the
                     node.";
                }
        uses site-network-access-top-level-cfg;
                description
          "List of accesses for a site.";
                  "MSDP parameters.";
              }
              description
        "List of accesses
                "Multicast global parameters for a site.";
    }
    description
      "Main block of the Network Access."; VPN
                 service.";
            }

  /* Main Blocks */

  container l3vpn-ntw {
    container vpn-profiles {
      uses vpn-profile-cfg;
            description
        "Container
              "List for VPN Profiles."; node.";
          }

        }
    container vpn-services {
      list vpn-service {
        key "vpn-id";
        uses service-status;
        uses vpn-svc-cfg;
        description
          "List of VPN services.";
      }
      description
        "Top-level container for the VPN services.";
    }
    description
      "Main container for L3VPN services management.";
  }
}
<CODE ENDS>

                                 Figure 26

11. 25

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

12.

10.  Security Considerations

   The YANG module specified in this document defines a 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].

   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 "ietf-l3vpn-ntw" module is used to manage L3 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 'vpn-service' leaf instance triggers the creation of an L3 VPN
   L3VPN Service in a Service Provider Network. service provider network.

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

   o  vpn-service:  'vpn-service': An attacker who is able to access network nodes can
      undertake various attacks, such as deleting a running L3 VPN L3VPN
      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 L3 VPN Service. L3VPN Service or adding a new
      network access.  Such activity can be detected by adequately
      monitoring and tracking network configuration changes.

   o  COMPLETE rest of critical data nodes and subtrees

   Some of the readable data nodes in this YANG the "ietf-l3vpn-ntw" 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  'customer-name' and ip-connection: 'ip-connection': An attacker can retrieve privacy-
      related
      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.

   Summing up,

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

   o  Malicious clients attempting to delete or modify services VPN services.

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

   o  Unauthorized clients attempting to read VPN service information

13. related
      information.

11.  Acknowledgements

   Thanks to Adrian Farrel and Miguel Cros for the suggestions on the
   document.  Thanks to Philip Eardlay for the review.  Lots of thanks
   for the discussions on opsawg mailing list and at IETF meeting.

   This work was supported in part by the European Commission funded
   H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727).

14.

12.  Contributors

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

   Daniel King
   Old Dog Consulting
   Email: daniel@olddog.co.uk

   Daniel Voyer
   Bell Canada
   Email: daniel.voyer@bell.ca

   Luay Jalil
   Verizon
   Email: luay.jalil@verizon.com

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

   Stephane Litkowski
   Cisco
   Email: slitkows@cisco.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>

15.

13.  References

15.1.

13.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-01 (work in progress), September 2020.

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

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

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

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

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

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

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

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

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

15.2.

   [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.  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-idr-bgp-model]
              Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP
              YANG Model for Service Provider Networks", draft-ietf-idr-
              bgp-model-08
              bgp-model-09 (work in progress), February June 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-00
              model-02 (work in progress), July 2020.

   [RFC3618]  Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source
              Discovery Protocol (MSDP)", RFC 3618,
              DOI 10.17487/RFC3618, October 2019. 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>.

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

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

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

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

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

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

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

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

Appendix A.  Implementation Status  L3VPN Examples

A.1.  Nokia Implementation

   Nokia has  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 draft implementation of
   service that meets the IETF L3NM model.

   The implementation SLA requirements.

   As it is a prototype and shown in the Figure 26, typically, an eNodeB (CE) is currently being planned for
   production.

   Nokia NSP (Network Services Platform) supports integration
   directly connected to the access routers of
   standard models with the Intent Manager framework.  NSP platform
   provides hot pluggable model definitions mobile backhaul and implementations which
   would enable defining models where standardization is in progress
   their logical interfaces (one or
   non-existent.  With pluggable architecture for model and
   implementation injections, NSP also serves as many according to the 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        |  10.0.0.1        |
         |   eNodeB    |>--------/------->|...........       |
         |             |          Vlan 1  |          |       |
         |             |>--------/------->|......    |       |
         |             |          Vlan 2  |     |    |       |
         |             | Direct           |  +-------------+ |
         +-------------+ Routing          |  | vpn-node-id | |
                                          |  | 44          | |
                                          |  +-------------+ |
                                          |                  |
                                          +------------------+

                    Figure 26: Mobile Backhaul Example

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

   First: Create the 4G VPN Service (Figure 27).

   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"
         }
       ]
     }
   }

                       Figure 27: Create VPN Service

   Second: Create a Multi-Layer, Multi-
   Domain controller.

   The Nokia implementation VPN Node as depicted in Figure 28.  In this type of L3NM covers,
   service, the following

   a) RESTConf support
   b) Configuration of L3 IP VPN Services.  Create/Get/Query/Delete
   supported on the following operations.

   * Site

   * Site-Bearer

   * VpnService

   * IEProfile

   * VpnNode

   * Site Network Access

   * Site Attachments

   c) Supports translations Node is equivalent to the Device Model (Standard /
   Properietary)

   draft-ietf-opsawg-l3sm-l3nm-00

   The current implementation is proprietary, so under no terms VRF configured in the
   current implementation can be used.

   Contact information: Sriram Krishnamurthy
   (sriram.krishnamurthy@nokia.com)

A.2.  Huawei Implementation

   The organization responsible for
   physical device ('ne-id'=10.0.0.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": "10.0.0.1",
           "local-autonomous-system": "65550",
           "rd": "0:65550:1",
           "vpn-targets": {
             "vpn-target": [
               {
                 "id": "1",
                 "route-targets": [
                   "0:65550:1"
                 ],
                 "route-target-type": "both"
               }
             ]
           }
         }
       ]
     }
   }

                        Figure 28: Create VPN Node

   Finally, two VPN Network Accesses are created using the implementation, if any.

   Huawei Technologies Co.,Ltd.

   The implementation's name and/or same physical
   port ('port-id'=1/1/1).  Each 'vpn-network-access' has a link particular
   VLAN (1,2) to a web page where differentiate the
   implementation or a description of it can be found.

   NCE V1R19C00

   A brief general description.

   This section provides an implementation report summary for Layer 3 traffic between: Sync and data
   (Figure 29).

   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": "1/1/1.1",
           "port-id": "1/1/1",
           "description": "Interface SYNC to eNODE-B",
           "status": {
             "admin-enabled": "true"
           },
           "vpn-network-access-type": "vpn-common:point-to-point",
           "ip-connection": {
             "ipv4": {
               "address-allocation-type": "static-address",
               "static-addresses": {
                 "primary-address": "1",
                 "address": [
                   {
                     "address-id": "1",
                     "s-provider-address": "192.0.2.1",
                     "s-customer-address": "192.0.2.1",
                     "s-prefix-length": 32
                   }
                 ]
               }
             }
           },
           "routing-protocols": {
             "routing-protocol": [
               {
                 "id": "1",
                 "type": "vpn-common:direct"
               }
             ]
           }
         },
         {
           "vpn-network-access-id": "1/1/1.2",
           "port-id": "1/1/1",
           "description": "Interface DATA to eNODE-B",
           "status": {
             "admin-enabled": "true"
           },
           "ip-connection": {
             "ipv4": {
               "address-allocation-type": "static-address",
               "static-addresses": {
                 "primary-address": "1",
                 "address": [
                   {
                     "address-id": "1",
                     "s-provider-address": "192.0.2.1",
                     "s-customer-address": "192.0.2.2",
                     "s-prefix-length": 32
                   }
                 ]

               }
             }
           },
           "routing-protocols": {
             "routing-protocol": [
               {
                 "id": "1",
                 "type": "vpn-common:direct"
               }
             ]
           }
         }
       ]
     }
   }

                   Figure 29: Create VPN Network Model.  Layer 3 Access

A.2.  Multicast VPN Network Model is available at:
   https://tools.ietf.org/html/draft-ietf-opsawg-l3sm-l3nm-00

   The implementation's level of maturity: research, prototype, alpha,
   beta, production, widely used, etc.

   Right now, the data model is still subject to change, therefore it is
   still a Prototype, not put into production yet.

   Coverage: which parts of the protocol specification are implemented.

   We have implemented pruned L3NM model with the following parameters

   module: ietf-l3vpn-ntw
   +--rw l3vpn-ntw
      +--rw vpn-profiles
      |  +--rw valid-provider-identifiers
      |     +--rw qos-profile-identifier* [id]
      |     |  +--rw id    string
      +--rw vpn-services
      |  +--rw vpn-service* [vpn-id]
      |     +--rw vpn-id                  svc-id
      |     +--rw vpn-service-topology?   identityref
      |     +--rw description?            string
      |     +--rw vpn-nodes
      |     |  +--rw vpn-node* [vpn-node-id ne-id]
      |     |     +--rw vpn-node-id        string
      |     |     +--rw description?       string
      |     |     +--rw ne-id              string
      |     |     +--rw node-role?         identityref
      |     |     +--rw rd?                rt-types:route-distinguisher
      |     |     +--rw vpn-targets
      |     |     +--rw maximum-routes
      |     |     |  +--rw address-family* [af]
      |     |     |     +--rw af                address-family
      |     |     |     +--rw maximum-routes?   uint32
      +--rw sites
         +--rw site* [site-id]
            +--rw site-id                  svc-id
            +--rw locations
            |  +--rw location* [location-id]
            |     +--rw location-id     svc-id
            +--rw site-bearers
            |  +--rw bearer* [bearer-id]
            |     +--rw bearer-id    string
            |     +--rw ne-id?       string
            |     +--rw port-id?     string
            +--rw site-network-accesses
               +--rw site-network-access* [site-network-access-id]
                  +--rw site-network-access-id      svc-id
                  +--rw site-network-access-type?   ref
                  +--rw bearer
                  |  +--rw bearer-reference?   {bearer-reference}?
                  |  +--rw connection
                  |  |  +--rw encapsulation-type?   identityref
                  |  |  +--rw tagged-interface
                  |  |     +--rw type?                identityref
                  |  |     +--rw dot1q-vlan-tagged {dot1q}?
                  |  |     |  +--rw cvlan-id    uint16
                  |  |     +--rw qinq {qinq}?
                  |  |     |  +--rw svlan-id    uint16
                  |  |     |  +--rw cvlan-id    uint16
                  +--rw ip-connection
                  |  +--rw ipv4 {ipv4}?
                  |  |  +--rw dhcp-relay
                  |  |  |  +--rw customer-dhcp-servers
                  |  |  |     +--rw server-ip-address*   inet
                  |  |  +--rw addresses 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 |     +--rw provider-address?   inet:ipv4-address
                  |  source   |     +--rw customer-address?   inet:ipv4-address   +------+     +------+    |   IP/MPLS |     +--rw prefix-length?      uint8
                  +--rw
                  +-----------+                            +-----------+

                Figure 30: Multicast L3VPN Service Example

   To configure a Multicast L3VPN service
                  |  +--rw qos {qos}?
                  |  |  +--rw qos-profile
                  |  |     +--rw (qos-profile)?
                  |  |        +--:(standard)
                  |  |        |  +--rw profile?   leafreaf
                  +--rw routing-protocols
                  |  +--rw routing-protocol* [type]
                  |     +--rw type                identityref
                  |     +--rw ospf {rtg-ospf}?
                  |     |  +--rw address-family*   address-family
                  |     |  +--rw area-address      yang:dotted-quad
                  |     |  +--rw metric?           uint16
                  |     |  +--rw security
                  |     |  |  +--rw auth-key?   string
                  |     +--rw bgp {rtg-bgp}?
                  |     |  +--rw autonomous-system    uint32
                  |     |  +--rw address-family*      address-family
                  |     |  +--rw neighbor?            inet:ip-address
                  |     |  +--rw multihop?            uint8
                  |     |  +--rw security
                  |     |     +--rw auth-key?   string
                  |     +--rw static
                  |     |  +--rw cascaded-lan-prefixes
                  |     |     +--rw ipv4-lan-prefixes*  {ipv4}?
                  |     |     |  +--rw lan         inet:ipv4-prefix
                  |     |     |  +--rw lan-tag?    string
                  |     |     |  +--rw next-hop    inet:ipv4-address
                  +--rw node-id?                    leafreaf
                  +--rw service-id?                 leafreaf
                  +--rw access-group-id?            yang:uuid using the L3NM model the
   procedure and the JSON with the data structure is the following:

   First, the multicast service is created (see the excerpt of the
   request message body shown in Figure 27

   Use Cases we have implemented include:

   (a).Create 31)
   {
     "ietf-l3vpn-ntw:vpn-services": {
       "vpn-service": [
         {
           "vpn-id": "Multicast-IPTV",
           "customer-name": "310",
           "vpn-service-topology": "vpn-common:hub-spoke",
           "description": "Multicast IPTV VPN

   (b).Create Site

   (c).Create/add bearers to an existing Site

   (d).Create/Include Site Network Access into service"
         }
       ]
     }
   }

      Figure 31: Create Multicast VPN nodes.

   Version compatibility: what version/versions Service (Excerpt of the Internet-Draft
   are known to be implemented.

   draft-ietf-opsawg-l3sm-l3nm-00

   Licensing: the terms under which the implementation can be used.  For
   example: proprietary, royalty licensing, freely distributable with
   acknowledgement (BSD style), freely distributable with requirement to
   redistribute source (General Public License (GPL) style), and other
   (specify).

   Not available yet.

   Implementation experience: any useful information Message
                               Request Body)

   Then, the implementers
   want to share with VPN nodes are created (see the community.

   Contact information: ideally a person's name and email address, but
   possibly just a URL or mailing list.

   Qin Wu (bill.wu@huawei.com)

   The date when information about this particular implementation was
   last updated.

   2019-09-30

   List other implementations that have been tested for
   interoperability.

   Nokia

A.3.  Infinera Implementation

   Infinera has a draft implementation excerpt of the IETF L3NM model.  The
   implementation is request
   message body shown in beta state and is currently being tested and
   integrated with other suppliers controllers supporting Figure 32).  In this same
   model.  Infinera is supporting example, the L3NM model VPN Node will
   represent VRF configured in its Transcend
   Maestro Multi-layer, Multi-domain Controller.

   The Infinera implementation the physical device.

   {
     "ietf-l3vpn-ntw:vpn-node": [
       {
         "vpn-node-id": "500003105",
         "ne-id": "10.250.2.202",
         "autonomous-system": "3816",
         "description": "VRF_IPTV_MULTICAST",
         "router-id": "10.250.2.202",
         "address-family": "ipv4",
         "node-role": "vpn-common:hub-role",
         "rd": "3816:31050202",
         "multicast": {
           "enabled": "true",
           "rp": {
             "rp-group-mappings": {
               "rp-group-mapping": [
                 {
                   "id": "1",
                   "rp-address": "172.19.48.17",
                   "groups": {
                     "group": [
                       {
                         "id": "1",
                         "group-address": "239.130.0.0/15"
                       }
                     ]
                   }
                 }
               ]
             },
             "rp-discovery": {
               "rp-discovery-type": "vpn-common:static-rp"
             }
           }
         }
       }
     ]
   }

   Figure 32: Create Multicast VPN Node (Excerpt of L3NM covers discovery and
   configuration the Message Request
                                   Body)

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

    {
     "ietf-l3vpn-ntw:vpn-network-access": {
       "vpn-network-access-id": "1/1/1",
       "description": "Connected_to_source",
       "status": {
         "admin-enabled": "true"
       },
       "vpn-network-access-type": "vpn-common:point-to-point",
       "ip-connection": {
         "ipv4": {
           "address-allocation-type": "static-address",
           "static-addresses": {
             "primary-address": "1",
             "address": [
               {
                 "address-id": "1",
                 "s-provider-address": "172.19.48.1",
                 "s-prefix-length": 30
               }
             ]
           }
         }
       },
       "routing-protocols": {
         "routing-protocol": [
           {
             "id": "1",
             "type": "vpn-common:bgp",
             "bgp": {
               "peer-autonomous-system": "6500",
               "local-autonomous-system": "3816",
               "address-family": "ipv4",
               "neighbor": "172.19.48.2",
               "description": "Connected to CE"
             }
           }
         ]
       },
       "service": {
         "multicast": {
           "multicast-site-type": "source-only",
           "multicast-address-family": {
             "ipv4": "true"
           },
           "protocol-type": "router"
         }
       }
     }
   }
   Figure 33: Create VPN services, and is supporting both North-Bound
   (server) and South-Bound (client) functionality.  Versions 01 and 02 Network Access (Excerpt of the model are supported.

   The current implementation is proprietary, so under no terms the
   current implementation Message Request
                                   Body)

Appendix B.  Implementation Status

B.1.  Nokia Implementation

   Details can be used.

   Contact information: Janne Karvonen (JKarvonen@infinera.com)

   26 October is the date when information about this particular
   implementation was last updated.

A.4.  Ribbon-ECI found at: https://github.com/IETF-OPSAWG-
   WG/l3nm/blob/master/Implementattion/Nokia.txt

B.2.  Huawei Implementation

   Ribbon-ECI Controller (Muse) has multilayer provisioning abilities
   from the optical layer up to the IP layer.  With respect to ATCN
   hierarchy model, Ribbon-ECI controller

   Details can be placed in at the level
   of MDSC and serve as a service orchestrator or at the level of PNC as
   a SDN controller.  Additional information found at: https://github.com/IETF-OPSAWG-
   WG/l3nm/blob/master/Implementattion/Huawei.txt

B.3.  Infinera Implementation

   Details can be found at
   https://www.ecitele.com/muse-network-service-apps/ The L3VPN
   Fulfillment component, which is currently in beta maturity level, is
   designed to support L3SM (RFC8299) for L3VPN service creation and
   activation, is implemented with a data model similar to the L3NM and
   translates it to the device model (ietf-routing-instance and ietf-
   interfaces).

   In addition, the L3VPN Fulfillment component interface include REST
   API with the following methods:

   o  Create service

   o  Edit service

   o  Get service details

   o  Delete service

   o  Notification (registration based)

   L3NM model coverage (several augmentations and deviations applied):

   o  vpn-service

   o  vpn-id
   o  uuid

   o  vpn-service-topology

   o  customer-name

   o  description

   o  slice-id

   o  service-status

   o  vpn-nodes

   o  ne-id

   o  vpn-node-id

   o  uuid

   o  autonomous-system

   o  rd

   o  vpn-targets

   o  vpn-network-accesses

   o  tunnel-policy

   o  export-policy

   o  routing protocol

   o  bgp

   o  static

   o  vpn-network-access

   o  vpn-network-access-id

   o  uuid

   o  statu

   o  connection
   o  tagged-interface

   o  cvlan-id

   o  ip-connection

   o  dhcp-relay

   o  static-addresses

   o  service

   o  qos-profile

   o  bw-profile 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

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