OPSAWG                                                         A. Aguado                                                        S. Barguil
Internet-Draft                                                     Nokia
Intended status: Standards Track                                  O. Gonzalez de Dios, Ed.
Intended status: Standards Track                              Telefonica
Expires: May 20, September 10, 2020                                           V. Lopez
                                                              Telefonica
                                                                D. Voyer
                                                             Bell Canada                                 M. Boucadair
                                                                  Orange
                                                                L. Munoz
                                                                Vodafone
                                                       November 17, 2019
                                                               A. Aguado
                                                                   Nokia
                                                          March 09, 2020

                    A Layer 3 VPN Network YANG Model
                     draft-ietf-opsawg-l3sm-l3nm-01
                     draft-ietf-opsawg-l3sm-l3nm-02

Abstract

   RFC8299

   This document defines a L3VPN Service L3 VPN Network YANG data Model (L3SM) Data model, called L3NM
   that can be used for communication between customers and VPN service providers.
   That data model plays to manage the role provisioning of Layer 3 VPN services
   within a Customer Service Model, according
   to the terminology defined in RFC8309, and is as such adequate for
   service negotiation and order handling matters.

   There Provider Network.  The module is a need for a more network-centric YANG data model meant to be used
   in the communication between the entity that interacts directly with
   the customer, the service orchestrator, (either fully automated or by
   a
   human operator) and Network Controller to derive the entity in charge of network orchestration and
   control (a.k.a., configuration information that
   will be sent to relevant network controller/orchestrator).

   This document specifies a devices.

   The L3VPN Network YANG Model (L3NM) to
   facilitate can also facilitates the
   communication between a service orchestrator and a network
   controller/orchestrator.  Such data  The model provides a network-centric view
   of the L3VPN services.

   The Yang model proposed L3NM YANG module is limited to aimed at managing BGP PE-based Layer 3 VPNs
   as described in RFCs 4026, 4110, 4110 and 4364 and Multicast VPNs as
   described in RFCs 6037, 6513 and 4364. 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 May 20, September 10, 2020.

Copyright Notice

   Copyright (c) 2019 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
     1.1.  Terminology
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   3.  Terminology . . . . .   4
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   5
   2. . .   4
   4.  Reference Architecture  . . . . . . . . . . . . . . . . . . .   6
   3.  Description of the L3NM
   5.  Relation with other YANG Module Models . . . . . . . . . . . . . . .   8
     3.1.  Structure
   6.  Description of the L3NM YANG Module . . . . . . . . . . . . . . . . .   9
     3.2.  Modeling a L3 VPN Service . . .  10
     6.1.  Overall Structure of the Module . . . . . . . . . . . . .   9
       3.2.1.  10
     6.2.  VPN node Profiles  . . . . . . . . . . . . . . . . . . . . . .  10
         3.2.1.1.
     6.3.  Modeling a Layer 3 VPN Network Access Service  . . . . . . . . . . . . .  11
       6.3.1.  Service Status  . .  11
           3.2.1.1.1.  Connection . . . . . . . . . . . . . . . . .  11
           3.2.1.1.2.  IP Connection  12
       6.3.2.  VPN Node  . . . . . . . . . . . . . . . . .  13
           3.2.1.1.3.  Routing Protocols . . . . .  13
         6.3.2.1.  Node Status . . . . . . . . .  14
       3.2.2.  Concept of Import/Export Profiles . . . . . . . . . .  15
       3.2.3.  Multicast
         6.3.2.2.  VPN Network Access  . . . . . . . . . . . . . . .  15
           6.3.2.2.1.  Connection  . . . . . . .  16

     3.3.  VPN profiles . . . . . . . . . .  17
           6.3.2.2.2.  IP Connections  . . . . . . . . . . . .  16
     3.4.  Model tree . . .  20
           6.3.2.2.3.  CE PE Routing Protocols . . . . . . . . . . .  22
         6.3.2.3.  Multicast . . . . . . . . . . . .  17
   4.  Use . . . . . . . .  26
       6.3.3.  Concept of the Data Model Import/Export Profiles . . . . . . . . . .  28
       6.3.4.  Underlay Transport  . . . . . . . . . .  23
     4.1.  Multi-Domain Resource Management . . . . . . .  28
   7.  L3NM Module Tree Structure  . . . . .  23
   5.  Relation with other Yang Models . . . . . . . . . . . .  28
   8.  Sample Uses of the L3NM Data Model  . . .  23
     5.1.  Relation with L3SM . . . . . . . . . .  39
     8.1.  Enterprise L3 VPN Services  . . . . . . . . .  23
     5.2.  Relation with Network Topology . . . . . .  39
     8.2.  Multi-Domain Resource Management  . . . . . . .  24
     5.3.  Relation with Device Models . . . . .  39
     8.3.  Management of Multicast services  . . . . . . . . . .  24
   6. . .  39
   9.  L3VPN Examples  . . . . . . . . . . . . . . . . . . . . . . .  24
     6.1.  40
     9.1.  4G VPN Provissioning Example  . . . . . . . . . . . . . .  24
   7.  Yang Module  40
     9.2.  Multicast VPN Provisioning Example  . . . . . . . . . . .  44
   10. L3NM YANG Module  . . . . . . . . . . . . . . . . . .  26
   8. . . . .  46
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  89
   9. 108
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  90
   10. Implementation Status . . . 109
   13. Acknowledgements  . . . . . . . . . . . . . . . . .  91
     10.1.  Nokia Implementation . . . . . 110
   14. Contributors  . . . . . . . . . . . . .  91
     10.2.  Huawei Implementation . . . . . . . . . . . 110
   15. References  . . . . . .  92
     10.3.  Infinera Implementation . . . . . . . . . . . . . . . .  96
   11. Acknowledgements . . . 111
     15.1.  Normative References . . . . . . . . . . . . . . . . . . 111
     15.2.  Informative References .  96
   12. Contributors . . . . . . . . . . . . . . . . 112
   Appendix A.  Implementation Status  . . . . . . . .  96
   13. References . . . . . . . 113
     A.1.  Nokia Implementation  . . . . . . . . . . . . . . . . . .  97
     13.1.  Normative References 113
     A.2.  Huawei Implementation . . . . . . . . . . . . . . . . . .  97
     13.2.  Informative References 114
     A.3.  Infinera Implementation . . . . . . . . . . . . . . . . .  98 118
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  99 118

1.  Introduction

   [RFC8299] defines an 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 services,
   and provides an abstracted view of the customer's requested services.
   That aproach 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 document is called L3VPN Network
   Model (L3NM).  The L3NM module is aimed at providing a network-
   centric view of L3 VPN Services.  The 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 orchestration interface, where logical resources (such
   as route targets or route distinguishers) must be synchronized.

   This document does not obsolete, but uses, the definitions in
   [RFC8299].  These two modules are used for similar objectives but
   with differents 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 attribute 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" 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].

1.1.

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 in [RFC8340].

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

   This document makes use of the following terms:

   o  L3 VPN Customer Service Model (L3SM): Describes the requirements
      of a L3 VPN that interconnects a set of sites from the point of
      view of the customer.  The customer service model does not provide
      details on the Service Provider Network.  The L3 VPN Customer
      Service model is defined in [RFC8299].

   o  L3 VPN Service Network Model (L3NM): A YANG module that describes
      a VPN Service in the Service Provider Network.  It containts 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.  The Service Orchestrator interacts with the
      customer using L3SM.  The Service Orchestrator is responsible of
      the CE-PE attachment circuits, the PE selection, and requesting
      the VPN service to the network controller.

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

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

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

   o  VPN Site (vpn-site): A VPN customer's location that is connected
      to the Service Provider network via a CE-PE link, which can access
      at least one VPN [RFC4176].

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

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

1.2.  Requirements Language

4.  Reference Architecture

   Figure 1 depicts the reference architecture for L3NM.  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.

2.  Reference Architecture

   Figure 1 depices the reference architecture for L3NM.  The figure is
   an expansion of the architecture presented 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
   dediciated
   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.

   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

   The L3SM and L3NM modules may also be set 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

3.  Description of

5.  Relation with other YANG Models

   As discussed in the previous section, the L3NM YANG Module

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

3.1.  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 Services managed in the service provider Service Provider network.  The
   module allows to create a new VPN service by adding a
   new instance of 'vpn-service'.  The 'vpn-service' is the data
   structure that abstracts the VPN Service.

   The 'vpn-profiles' container allows the provider to maintain provides a set network-wise view of
   commmon VPN profiles that apply to several VPN Services.

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

                                 Figure 3

3.2.  Modeling a L3 VPN Service

   The 'vpn-service' is the data structure that abstracts a VPN Service
   in the Service Provider Network.  Every 'vpn-service' has a unique
   identifier: vpn-id. service.  Such vpn-id view is
   only meaningful locally visible within the Network controller.  In order to facilitate the recognition of
   the service, a 'customer-name' Service Provider and is not exposed outside.
   The following discusses how L3NM interfaces with other YANG modules:

   L3SM:  L3NM is not a 'description' may be included. Customer Service Model.

      The topology internal view of the VPN service (L3NM) may be mapped to an
      external view which is expressed in the 'vpn-service-
   topology' leaf.

   A VPN Service is built by adding instances of 'vpn-node' visible to Customers : L3VPN Service YANG
      data Model (L3SM) [RFC8299].

      Typically, the 'vpn-
   nodes' container.  The 'vpn-node' is an abstractions L3NM module can be fed with inputs that represent are
      requested by Customers, typically, relying upon a
   set L3SM template.
      Concretely, some parts of policies applied to a network node and that belong to a single
   'vpn-service'.  A 'vpn-node' contains 'vpn_network_accesses', which
   are the interfaces involved in the creation L3SM module can be directly mapped
      into L3NM while other parts are generated as a function of the VPN.  The customer
   sites
      requested service and local guidelines.  Some other parts are connected
      local to the 'vpn_network_accesses'. Service Provider and do not map directly to L3SM.

      Note that, as
   this is a network data model, that the information about customers site is
   not needed.  Such information, is relevant in use of L3NM within a Service Provider does assume
      nor preclude exposing the L3SM model.

        +--rw vpn-service* [vpn-id]
              +--rw vpn-id                  svc-id
              +--rw customer-name?          string
              +--rw vpn-service-topology?   identityref
              +--rw description?            string
              +--rw ie-profiles
              |  ...
              +--rw vpn-nodes
              |   ...
              +--rw multicast

                                 Figure 4

3.2.1. VPN node

   The 'vpn-node' service via L3SM.  This is an abstraction that represents a set
      deployment-specific.  Nevertheless, the design of common
   policies applied in a given network node (tipcally a PE) and belong
   to one L3 VPN Service.  In order L3NM tries to indicate the network node where
   the 'vpn-node' applies
      align as much as possible with the features supported by the ne-id MUST be facilitated.  The 'vpn-
   node' includes a parameter L3SM
      to indicate in which network node it is
   applied.  In ease grafting both L3NM and L3SM for the case sake of highly
      automated VPN service provisioning and delivery.

   Network Topology Modules:  A L3VPN involves nodes that the ne-id points to are part of a specific PE,
      topology managed by the
   vpn_node will likely Service Provider Backbone network.  Such
      topology can be mapped into a vrf in represented as using the node.  However, 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
   model also allows to point to an abstract node.  In this case, actual
      activation and provisioning of the
   network controller VPN service will decide how involve a
      variety of device modules to split tweak the vpn_node into vrfs.
   For required functions for the cases
      delivery of the logical resources service.  These functions are managed outside the network
   controller, the model allows to explicitely indicate the logical
   resources such as Route targets and Route distinguishers (RT,RD).

   Under supported by the VPN Node container, VPN Network Acesses
      nodes and can be created.
   The VPN Network Acess represents the point managed using device YANG modules.  A non-
      comprehensive list of such device YANG modules is provided below:

      *  Routing management ([RFC8349])

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

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

      *  NAT management ([RFC8512])

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

      *  ACL ([RFC8519])
      How L3NM is used to which sites are
   connected.  Note that, unlike in L3SM, derive device-specific actions is
      implementation-specific.

6.  Description of the L3NM does not need YANG Module

   The L3NM module ('ietf-l3vpn-ntw') is meant to
   model the customer site, only the points where manage L3 VPNs in a
   service provider network.  In particular, the traffic from 'ietf-l3vpn-ntw' module
   can be used to create, modify, and retrieve L3VPN Services of a
   network.

   The detailed tree structure is provided in Figure 15.

6.1.  Overall Structure of the
   site are received.  Hence, 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 Network access contains the
   connectivity information between services
   managed within the service provider's Network and the
   customer premises. network. 'vpn-service' is the
   data structure that abstracts a VPN service (Section 6.3).

   The 'vpn-profiles' container is used by the provider to maintain a
   set of common VPN profiles have 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

6.2.  VPN Profiles

   The 'vpn-profiles' containers (Figure 4) allow the network provider
   to define and maintain a set of routing policies
   than can be applied during common VPN profiles that apply to
   several VPN services.  The exaact definition of the service creation. profiles is local
   to each network provider.

       +--rw vpn-node* [vpn-node-id ne-id] l3vpn-ntw
          +--rw vpn-node-id vpn-profiles
          |  +--rw valid-provider-identifiers
          |     +--rw cloud-identifier* [id] {l3vpn-svc:cloud-access}?
          |     |  +--rw id    string
          |     +--rw description? encryption-profile-identifier* [id]
          |     |  +--rw id    string
          |     +--rw ne-id qos-profile-identifier* [id]
          |     |  +--rw id    string
          |     +--rw router-id?              inet:ip-address bfd-profile-identifier* [id]
          |     |  +--rw address-family?         address-family id    string
          |     +--rw node-role?              identityref routing-profile-identifier* [id]
          |        +--rw rd?                     rt-types:route-distinguisher id    string
          +--rw vpn-targets
            .... vpn-services
              +--rw vpn-network-accesses
            .... vpn-service* [vpn-id]
                 ...

                   Figure 5

3.2.1.1. 4: VPN Network Access

   A 'vpn-network-access' represents an entry point to Profiles Tree Structure

6.3.  Modeling a Layer 3 VPN service.
   In other words, this container encloses the parameters that describe
   the access information for Service

   The 'vpn-service' is the traffic data structure that belongs to a particular
   L3 VPN.  As such, every vpn-network-access belongs to one and only
   one vpn-node.  As an example, abstracts a vpn-network-access includes
   information such as the connection on which VPN Service
   in the access Service Provider Network.  Each 'vpn-service' is defined
   (see uniquely
   identified by an identifier: 'vpn-id'.  Such 'vpn-id' is only
   meaningful locally within the section below), Network controller.

   In order to facilitate the encapsulation identification of the traffic, policies
   that are applied on the access, etc.

   A provisioning network controller (PNC) [RFC8453] will accept VPN
   requests containing this construct, using service, 'customer-
   name' and 'description' attributes may be provided.

   The 'vpn-service' parameters are:

   o  service-status: Allows the enclosed data to:
   configure control of the router's interface operative and
      administrative status of the service as a whole.

   o  vpn-id: Unique identifier of the L3VPN Service within L3NM scope.

   o  l3sm-vpn-id: Refers to include the parameters described
   at L3SNM Id of this service.  This
      identifier allows to easily correlate the vpn-network-access, include service as built in the given interface into
      network with a VRF,
   configuring service request.

   o  vpn-service-topology: Typical network topologies are supported.
      Hub-Spoke, Any-to-Any, and Custom.  Real deployment on the network
      is defined by the correct usage of import and export profiles

   o  ie-profiles: Define reusable import/export policies or schedulers for the incoming traffic, etc.

3.2.1.1.1.  Connection

   The definition same
      VPN-Service.  Described in detail in Section 6.3.3

   o  Underlay-Transport: Describes the preference for the transport
      technology to carry the traffic of a L3VPN is commonly specified not only at the IP
   layer, but also requires VPN-Service.

   A VPN service is typically built by adding instances of 'vpn-node' to identify parameters at
   the Ethernet
   layer, such as encapsulation type (e.g., VLAN, QinQ, QinAny, VxLAN,
   etc.). 'vpn-nodes' container.  The 'connection' container 'vpn-node' is an abstraction that
   represents and groups the a set of
   L2 connectivity from where policies applied to a network node and that
   belong to a single 'vpn-service'.

   A 'vpn-node' contains 'vpn-network-accesses', which are the traffic of
   interfaces attached to the L3VPN in a particular VPN Network access by which the customer traffic is coming.

   Additionally,
   received.  Therefore, the bearer-reference (Section 3.2.1.1.1.3) and customer sites are connected to the
   pseudowire termination (Section 3.2.1.1.1.2) 'vpn-
   network-accesses'.  Note that, as this is supported.

3.2.1.1.1.1.  Encapsulation options

   Ethernet encapsulation description a network data model, the
   information about customers sites is not supported required in [RFC8299].
   However, this parameters are mandatory to configure the PE
   interfaces.  Thus, In the L3NM, these parameters uses the connection
   container inside model.  Such
   information, is rather relevant in the vpn-network-access.  This container defines
   protocols and parameters to enable connectivity at Layer 2.

                     +--rw connection
                       +--rw encapsulation-type?   identityref
                         +--rw tagged-interface
                            +--rw type?                identityref L3SM model.

   +--rw dot1q-vlan-tagged {dot1q}?
                            | vpn-service* [vpn-id]
      +--rw tag-type?   identityref service-status
      |  ...
      +--rw cvlan-id?   uint16
                            +--rw priority-tagged
                            | vpn-id                  l3vpn-svc:svc-id
      +--rw tag-type?   identityref l3sm-vpn-id?            l3vpn-svc:svc-id
      +--rw qinq {qinq}?
                            | customer-name?          string
      +--rw tag-type? vpn-service-topology?   identityref
                            |  +--rw svlan-id    uint16
                            |
      +--rw cvlan-id    uint16 description?            string
      +--rw qinany {qinany}? ie-profiles
      |  ...
      +--rw tag-type?   identityref underlay-transport
      |  +--rw svlan-id    uint16
                            +--rw vxlan {vxlan}?
                               +--rw vni-id       uint32
                               +--rw peer-mode?   identityref
                               +--rw peer-list* [peer-ip]
                                  +--rw peer-ip    inet:ip-address  ...

                   Figure 6

3.2.1.1.1.2.  Remote Far End Configuration

   Depending on the control plane implementation, different network
   scenarios might require additional information for the L3VPN service 5: vpn-service tree structure

6.3.1.  Service Status

   The L3NM module allows to be configured track service status ('service-status') of
   a given VPN service (Figure 6).  Both operational and active. administrative
   status are maintained together with a timestamp.  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
   service can be coordinated between both management systems.  This
   definition requires for every management system participant in the
   VPN to receive created but not just their own sites put into effect.

   'admin' and site-network-accesses,
   but also 'ops' status can be used as trigger to receive information about external ones, identified detect service
   anomalies.  For example, a service that is declared at the service
   layer as an
   external site-network-access-type.  In addition, this particular
   site-network-access active but still inactive at the network layer is augmented an
   indication that network provision actions are needed to include align the loopback address of
   observed service with the far-end (remote/external) PE router. expected service status.

     +--rw bearer l3vpn-ntw
        +--rw connection vpn-profiles
        |  ...
        +--rw pseudowire vpn-services
           +--rw vcid?   uint32 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 7

3.2.1.1.1.3.  Bearers

   A site, as per [RFC4176] represents a 6: VPN customer's location that is
   connected to the Service Provider Status Tree Structure

6.3.2.  VPN Node

   The 'vpn-node' is 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 L3 VPN Service.  In order to indicate the Service
   Provider network is node where
   the bearer.  Every site is associated with 'vpn-node' applies the 'ne-id' must be indicated.  The 'vpn-node'
   includes a list
   of bearers.  A bearer parameter to indicate in which network node it is the layer two connections with the site. applied.
   In the module it is assumed case that the bearer has been allocated by the
   Service Provider at the service orchestration step.  The bearer is
   associated 'ne-id' points to a network element and a port.  Hence, a bearer is just
   a bearer-reference to allow the translation between L3SM and L3NM.

3.2.1.1.2.  IP Connection

   IP Connection container has the parameters of specific PE, the vpn-network-access
   addressing information.  The address allocated 'vpn-node'
   will likely be mapped into a VRF in this container
   would represent the PE interface address configuration.  The IP
   Connection container is designed node.  However, the model
   also allows to support dual stack (IPv4/IPv6)
   and three options point to set the ip address: Provider DHCP, DHCP relay or
   static addressing. an abstract node.  In this case, the case of network
   controller will decide how to split the static addressing 'vpn-node' into VRFs.
   Additionally the model supports 'vpn-node' parameters are:

   o  status: Allows the
   assignation control of several IP addresses in the same vpn-network-access.
   To identify which operative and administrative
      status of the addresses is 'vpn-node'.

   o  local-autonomous-system: Autonomous system of locally configured
      in the primary address instance.  It can be overwritten for specific purposes in
      the CE-PE BGP session.

   o  maximum-routes: Max-number of prefixes allowed in the
   connection vpn-node
      instance.

   o  rd and vpn-targets: For the "primary-address" reference must cases the logical resources are
      managed outside the network controller, the model allows to
      explicitely indicate the logical resources such as Route targets
      (RTs) and Route Distinguishers (RDs) (RT,RD).

   o  Multicast: Enable multicast traffic inside the vpn.  Detailed
      description in Section 6.3.2.3

   Under the VPN Node ('vpn-node') container, VPN Network Acesses ('vpn-
   network-access') can be created.  The VPN Network Acess represents
   the point to which sites are connected.  Note that, unlike in L3SM,
   the L3NM does not need 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 the customer premises.  The VPN profiles ('vpn-profiles')
   have a set with of routing policies than can be applied during the
   corresponding address-id. service
   creation.

   module: ietf-l3vpn-ntw
     +--rw ip-connection l3vpn-ntw
      +--rw ipv4 {ipv4}? vpn-profiles
      |  ...
      +--rw address-allocation-type?   identityref vpn-services
       +--rw provider-dhcp
                         ... vpn-service* [vpn-id]
          +--rw dhcp-relay vpn-id                  l3vpn-svc:svc-id
          + ...
          +--rw static-addresses vpn-nodes
           +--rw primary-address?   leafref vpn-node* [ne-id]
              +--rw address* [address-id]
                         ... vpn-node-id?               union
              +--rw ipv6 {ipv6}? local-autonomous-system?   inet:as-number
              +--rw address-allocation-type? description?               string
              +--rw ne-id                      string
              +--rw router-id?                 inet:ip-address
              +--rw address-family?
              |       l3vpn-svc:address-family
              +--rw node-role?                 identityref
              +--rw provider-dhcp
                         ... rd?
              |       rt-types:route-distinguisher
              +--rw dhcp-relay
                         ... vpn-targets
              |  +--rw static-addresses vpn-target* [id]
              |  |  +--rw primary-address? id                   int8
              |  |  +--rw route-targets* [route-target]
              |  |  |  +--rw route-target
              |  |  |          rt-types:route-target
              |  |  +--rw route-target-type
              |  |          rt-types:route-target-type
              |  +--rw vpn-policies
              |     +--rw import-policy?   leafref
              |     +--rw address* [address-id]
                             ...

                                 Figure 8

3.2.1.1.3.  Routing Protocols

   The model allows the Network Operator export-policy?   leafref
              +--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 maximum-routes
              |  +--rw address-family* [af]
              |     +--rw af
              |     |       l3vpn-svc:address-family
              |     +--rw maximum-routes?   uint32
              +--rw multicast {l3vpn-svc:multicast}?
              |  ...
              +--rw node-ie-profile?           leafref

                     Figure 7: VPN Node Tree Structure

6.3.2.1.  Node Status

   The L3NM module allows to configure one or more
   routing protocols associated with a particular vpn-network-access.
   This protocol will run between track the PE and status ('status') of the CE.  A routing protocol
   instance MUST have nodes
   involved in a type (e.g. bgp, ospf, etc.) VPN service (Figure 8).  Both operational and
   administrative status are maintained.  Mismatch between an identifier.
   The identifier is necessary when multiple instances of
   administrative status vs. the same
   protocol need to operational status can be configured.

   The model uses 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
              ...
              +--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.  VPN Network Access

   A 'vpn-network-access' represents an abstracted view of routing protocols.  When
   configuring multiple instances of the same protocol, this does not
   automatically imply that, from a device configuration perspective,
   there will be parallel instances (multiple processes) running.  It
   will be up entry point to a VPN service
   (Figure 9).  In other words, this container encloses the implementation to use parameters
   that describe the most appropriate
   deployment model. 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 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
   protocols:

   o  vrrp: takes one and only a list of address-family one 'vpn-node'.

   A 'vpn-network-access' includes information such as parameter.  VRRP
      instance is expected to run the connection on
   which the vpn-network-access interface.

   o  rip: takes only a list of address-family as parameter.  RIP
      instance access is expected to run defined (see Section 6.3.2.2.1), the
   encapsulation of the traffic, policies that are applied on the vpn-network-access interface.

   o  static: allows user to
   access, etc.

   A provisioning Network Controller (PNC) [RFC8453] will accept VPN
   requests containing this construct, using the enclosed data to:
   configure one or more IPv4 and IPv6 static
      routes.

   o  bgp: allows the user router's interface to configure a BGP neighbor including include the parameters like authentication using a key.  The authentication
      type will be driven by described
   at the implementation but 'vpn-network-access', include the model supports
      any authentication that uses a key as given interface into a parameter.  A BGP neighbor
      can support ipv4, ipv6, VRF,
   configuring policies or both address-families.  Again, it is up
      to the implementation to drive the device configuration (e.g.
      separate BGP sessions for Dual Stack, single session schedulers for Dual
      Stack, etc.).

   o  ospf: allows the user to configure OSPF to run on processing 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 the
      implementation to drive if OSPFv2 or v3 is used.

   Routing protocol configuration do not have any routing policy
   configuration.  Routing policies are low level device configurations
   that must not be part of an abstracted model.  Service Provider
   internal policies (such as incoming
   traffic, etc.

   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 port-id?
              |     |       l3vpn-svc:svc-id
              |     +--rw description?               string
              |     +--rw status
              |     |  +--rw admin-enabled?   boolean
              |     |  +--ro oper-status?     operational-type
              |     +--rw vpn-network-access-type?   identityref
              |     +--rw connection
              |     |  ...
              |     |  +--rw bearer
              |     |     ...
              |     +--rw ip-connection
              |     |  ...
              |     +--rw security filters) will be implemented as
   part
              |     |  ...
              |     +--rw routing-protocols
              |     |  ...
              |     +--rw service
              |        ...
              |  ...

                Figure 9: VPN Network Access Tree Structure

6.3.2.2.1.  Connection

   The definition of a L3VPN is commonly specified not only at the device configuration IP
   layer, but does not require any input from
   this model.  Some policies like primary/backup, load-balancing can be
   inferred from access-priority.

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

   Additionally, the PNC can identify
   RTs bearer-reference and RDs to be configured in the VRF.

3.2.3.  Multicast

   Multicast can be optionally enabled for a particular vpn-network-
   access.

   The model supports a single type of tree (ASM, SSM or bidirectional).

   When ASM is used, the model supports configuration of rendez-vous
   points.  RP discovery could be static, bsr-rp or auto-rp.  When
   static is used RP to multicast grouping mapping must be configured as
   part of the rp-group-mappings container.  The RP may be a provider
   node or a customer node.  When the RP is a customer node, the RP
   address must be configured using the rp-address leaf otherwise no RP
   address is needed.  The model supports RP redundancy through the rp-
   redundancy leaf.  How the redundancy is achieved is out of scope and pseudowire termination are
   supported.

   Ethernet encapsulation description is up to the implementation.  When a particular VPN using ASM
   requires a more optimal traffic delivery, the leaf optimal-traffic-
   delivery can be used.  When set not supported in [RFC8299].
   However, this parameters are mandatory to true, configure the implementation must use
   any mechanism to provide a more optimal traffic delivery for PE
   interfaces.  Thus, In the
   customer.  As an example, L3NM, these parameters uses the implementation can use RP tree to
   Shortest Path tree switchover or simply deploy additional RPs working
   in an anycast mode.

3.3.  VPN profiles

   The vpn-profiles containers allow connection
   container inside the network operator to maintain a
   set of commmon VPN Profiles that apply to several VPN Services.
   Through this vpn-network-access.  This container these common profiles can be created, modified defines
   protocols and deleted. parameters to enable connectivity at Layer 2.

   module: ietf-l3vpn-ntw
     +--rw l3vpn-ntw
      +--rw vpn-profiles
      |  ...
      +--rw valid-provider-identifiers
    | vpn-services
       +--rw cloud-identifier* [id] {cloud-access}?
    |     | vpn-service* [vpn-id]
          +--rw id    string
    | vpn-id                  l3vpn-svc:svc-id
          +  ...
           +--rw encryption-profile-identifier* [id]
    |     | vpn-node* [ne-id]
              +--rw id ne-id                      string
    |     +--rw qos-profile-identifier* [id]
    |     |
              + ...
              +--rw id    string vpn-network-accesses
              |  +--rw bfd-profile-identifier* vpn-network-access* [id]
              |     |     +--rw id    string
              |     +--rw routing-profile-identifier* [id]     |        +--rw id    string

                                 Figure 9

3.4.  Model tree

   The high-level model structure defined by this document is as shown
   below:

   module: ietf-l3vpn-ntw
   +--rw l3vpn-ntw
    +--rw vpn-profiles       l3vpn-svc:svc-id
              |  +--rw valid-provider-identifiers     + ...
              |     +--rw cloud-identifier* [id] {cloud-access}?
    | connection
              |  +--rw id    string     |  +--rw encryption-profile-identifier* [id]
    | encapsulation-type?   identityref
              |  +--rw id    string     |  +--rw qos-profile-identifier* [id] logical-interface
              |     |  +--rw id    string  |  +--rw bfd-profile-identifier* [id] peer-reference?   uint32
              |     |  +--rw id    string tagged-interface
              |     |     +--rw routing-profile-identifier* [id]  |  +--rw id    string
    +--rw vpn-services
     +--rw vpn-service* [vpn-id]
        +--rw vpn-id                  svc-id
        +--rw customer-name?          string
        +--rw vpn-service-topology? type?                identityref
        +--rw description?            string
        +--rw ie-profiles
              |  +--rw ie-profile* [ie-profile-id]     |     +--rw ie-profile-id    string  |  +--rw rd?
        | dot1q-vlan-tagged {dot1q}?
              |       rt-types:route-distinguisher     |     +--rw vpn-targets  |        +--rw vpn-target* [route-target]  |  +--rw route-target
        | tag-type?   identityref
              |       rt-types:route-target     |           +--rw route-target-type  |                   rt-types:route-target-type
        +--rw vpn-nodes  |  +--rw vpn-node* [vpn-node-id ne-id] cvlan-id?   uint16
              |     +--rw vpn-node-id             string     |     +--rw autonomous-system?      uint32  |  +--rw description?            string priority-tagged
              |     +--rw ne-id                   string     |     +--rw router-id?              inet:ip-address  |     +--rw address-family?         address-family  |  +--rw node-role? tag-type?   identityref
              |     +--rw rd?
        |     |       rt-types:route-distinguisher  |  +--rw vpn-targets qinq {qinq}?
              |     |  +--rw vpn-target* [route-target]  |  |  +--rw route-target
        | tag-type?   identityref
              |     |       rt-types:route-target  |  |  +--rw route-target-type
        | svlan-id    uint16
              |             rt-types:route-target-type     |     +--rw status  |  |  +--rw admin-enabled?   boolean
        |     |  +--ro oper-status?     operational-type cvlan-id    uint16
              |     +--rw vpn-network-accesses     |  |  +--rw vpn-network-access*
        |     |          [vpn-network-access-id] qinany {qinany}?
              |     |     +--rw vpn-network-access-id      svc-id  |  |  +--rw description?               string
        | tag-type?   identityref
              |     +--rw status     |  |  |  +--rw admin-enabled?   boolean
        |     | svlan-id    uint16
              |  +--ro oper-status?     operational-type     |  |  +--rw vpn-network-access-type?
        |     | vxlan {vxlan}?
              |       identityref     |  |     +--rw connection vni-id       uint32
              |     |  |     +--rw encapsulation-type? peer-mode?   identityref
              |     |  |     +--rw tagged-interface
        | peer-list* [peer-ip]
              |     |  |        +--rw type?
        | peer-ip    inet:ip-address
              |     |  +--rw bearer
              |     |       identityref     ...
              |     +--rw ip-connection
              |     |  ...
              |     +--rw dot1q-vlan-tagged {dot1q}?
        |     | security
              |     |  ...
              |     +--rw tag-type?   identityref
        |     | routing-protocols
              |     |  ...
              |     +--rw cvlan-id?   uint16
        |     |     |  |  +--rw priority-tagged
        |     |     |  |  |  +--rw tag-type?   identityref
        |     |     |  |  +--rw qinq {qinq}?
        |     |     | service
              |        ...
              |  ...

                  Figure 10: Encapsulation Tree Structure

   Depending on the control plane implementation, different network
   scenarios might require additional information for the 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.  This
   definition requires for every management system participant in the
   VPN to receive not just their own sites and site-network-accesses,
   but also to receive information about external ones, identified as an
   external site-network-access-type.  In addition, this particular
   site-network-access is augmented to include the loopback address of
   the far-end (remote/external) PE router.

   module: ietf-l3vpn-ntw
     +--rw tag-type?   identityref
        |     |     |  |  | l3vpn-ntw
      +--rw svlan-id    uint16
        |     |     |  | vpn-profiles
      |  ...
      +--rw cvlan-id    uint16
        |     |     |  | vpn-services
       +--rw qinany {qinany}?
        |     |     |  |  | vpn-service* [vpn-id]
          +--rw tag-type?   identityref
        |     |     |  |  | vpn-id                  l3vpn-svc:svc-id
          +  ...
           +--rw svlan-id    uint16
        |     |     |  | vpn-node* [ne-id]
              +--rw vxlan {vxlan}?
        |     |     |  | ne-id                      string
              + ...
              +--rw vni-id       uint32
        |     |     | vpn-network-accesses
              |  +--rw peer-mode?   identityref
        |     |     | vpn-network-access* [id]
              |     +--rw peer-list* [peer-ip] id
              |     |       l3vpn-svc:svc-id
              |     +  ...
              |     +--rw peer-ip
        |     |     | connection
              |                inet:ip-address     |  ...
              |     |  +--rw bearer
              |     |     |     +--rw bearer-reference?   string
              |     |     |     |       {bearer-reference}?
        |       {l3vpn-svc:bearer-reference}?
              |     |     +--rw pseudowire
              |     |     |  +--rw vcid?      uint32
              |     |     +--rw ip-connection
        |     |     |  +--rw ipv4 {ipv4}? far-end?   union
              |     |     +--rw vpls
              |     |        +--rw address-allocation-type? vcid?      union
              |     |        +--rw far-end?   union
              |     +--rw ip-connection
              |     |       identityref  ...
              |     +--rw security
              |     |  ...
              |     +--rw provider-dhcp
        |     | routing-protocols
              |     |  ...
              |     +--rw provider-address? service
              |        ...
              |  ...

                     Figure 11: Bearer Tree Structure

   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.

6.3.2.2.2.  IP Connections

   IP connection container (Figure 12) has the parameters of the 'vpn-
   network-access' addressing information.  The address allocated in
   this container would represent the PE interface address
   configuration.  The IP connection container is designed to support
   both IPv4 and IPv6.  It also supports three options for IP address
   assignment: Provider DHCP, DHCP relay, and static addressing.

   In the case of the static addressing, the model supports the
   assignment of several IP addresses in the same 'vpn-network-access'.
   To identify which of the addresses is the primary address of a
   connection ,the "primary-address" reference MUST be set with the
   corresponding 'address-id'.

   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-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
              |       inet:ipv4-address  +--rw vpn-network-access* [id]
              |     +--rw id
              |     |       l3vpn-svc:svc-id
              |     +  ...
              |     +--rw prefix-length? connection
              |     |  ...
              |     +--rw ip-connection
              |     |  +--rw ipv4 {l3vpn-svc:ipv4}?
              |       uint8     |  |  +--rw address-allocation-type?
              |     |  |  +--rw (address-assign)?  |       identityref
              |     |  |  +--rw provider-dhcp
              |     |  |     +--:(number)  |  +--rw provider-address?
              |     |  |  |  |       inet:ipv4-address
              |     |  |  |  +--rw number-of-dynamic-address? prefix-length?
              |     |  |  |  |       uint8
              |     |  |          uint16  |  +--rw (address-assign)?
              |     |  |  |     +--:(explicit)     +--:(number)
              |     |  |  |     |  +--rw customer-addresses number-of-dynamic-address?
              |     |  |  |     |          uint16
              |     |  |  |     +--:(explicit)
              |     |  |  |        +--rw address-group* customer-addresses
              |     |  |  |           +--rw address-group*
              |     |  |                   [group-id]  |                   [group-id]
              |     |  |  |              +--rw group-id
              |     |  |  |              |              |       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]
              |     |  |  |        +--rw address-id
        |     |     |  |        |          string
              |     |  |  |        +--rw provider-address?
              |     |  |        |        |       inet:ipv4-address
              |     |  |  |        +--rw customer-address?
              |     |  |        |        |       inet:ipv4-address
              |     |  |  |        +--rw prefix-length?
        |     |     |  |      uint8
              |     |     |  +--rw ipv6 {ipv6}?
        | {l3vpn-svc:ipv6}?
              |     |  |  +--rw address-allocation-type?
              |     |  |  |  |       identityref
              |     |  |  |  +--rw provider-dhcp
              |     |  |  |  |  +--rw provider-address?
              |     |  |  |  |  |       inet:ipv6-address
              |     |  |  |  |  +--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 {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 {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 {rtg-ospf}?
        |     |           |  +--rw address-family*
        |     |           | service
              |       ...

                  Figure 12: IP Connection Tree Structure

6.3.2.2.3.  CE PE Routing Protocols

   The model allows the Provider to configure one or more routing
   protocols associated with a particular 'vpn-network-access'
   (Figure 13).  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.

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

   o  VRRP: takes only a list of 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]
        |     |           | as parameter.  VRRP
      instance is expected to run on the 'vpn-network-access' interface.

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

   o  BGP: allows to configure a BGP neighbor including parameters like
      authentication using a key.  The authentication type will be
      driven by the implementation but 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 a given address family) or one
      neighbor (for both IPv4 and IPv6 of "address-family" attribute is
      set to both).  It is then up to the implementation to drive the
      device configuration.

   o  OSPF: allows the user to configure OSPF to run 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 the
      implementation to drive if OSPFv2 or v3 is used.

   o  IS-IS: allows the user to configure IS-IS to run 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.  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'.

   module: ietf-l3vpn-ntw
     +--rw target-site    svc-id
        |     |           | l3vpn-ntw
      +--rw metric?        uint16
        | vpn-profiles
      |  ...
      +--rw bgp {rtg-bgp}?
        |     | 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 autonomous-system    uint32 admin-enabled?   boolean
              |  +--ro oper-status?     operational-type
              +--rw vpn-network-accesses
              |  +--rw vpn-network-access* [id]
              |     +--rw address-family* id
              |     |       l3vpn-svc:svc-id
              |     +  ...
              |       address-family     +--rw connection
              |     |  ...
              |     +--rw neighbor? ip-connection
              |     |  ...
              |     |       inet:ip-address  +--rw oam
              |     |     ...
              |     +--rw multihop?            uint8 security
              |     |  ...
              |     +--rw security routing-protocols
              |     |  +--rw routing-protocol* [id]
              |     |     +--rw auth-key? id                  string
              |     |     +--rw static type?               identityref
              |     |     +--rw routing-profiles* [id]
              |     |     |  +--rw cascaded-lan-prefixes id      leafref
              |     |     |  +--rw ipv4-lan-prefixes* type?   ie-type
              |     |     +--rw ospf {l3vpn-svc:rtg-ospf}?
              |     |     |  +--rw address-family*
              |     |       [lan next-hop] {ipv4}?     |  |       l3vpn-svc:address-family
              |     |     |  +--rw lan area-address
              |     |     |  |       yang:dotted-quad
              |     |       inet:ipv4-prefix     |  +--rw metric?           uint16
              |     |     |  +--rw lan-tag?    string mtu?              uint16
              |     |     |  +--rw process-id?       uint16
              |     |     |  +--rw next-hop security
              |     |     |  |          inet:ipv4-address  +--rw auth-key?   string
              |     |     |  +--rw ipv6-lan-prefixes* sham-links
              |     |     |             [lan next-hop] {ipv6}?          {rtg-ospf-sham-link}?
              |     |     |     +--rw lan sham-link* [target-site]
              |     |     |        +--rw target-site
              |       inet:ipv6-prefix     |     |        |        +--rw lan-tag?    string       l3vpn-svc:svc-id
              |     |     |        +--rw next-hop metric?        uint16
              |     |     +--rw bgp {l3vpn-svc:rtg-bgp}?
              |                inet:ipv6-address     |     |  +--rw rip {rtg-rip}? peer-autonomous-system
              |     |     |  |       inet:as-number
              |     |     |  +--rw address-family* local-autonomous-system?
              |     |     |          address-family  |       inet:as-number
              |           +--rw vrrp {rtg-vrrp}?     |     |  +--rw address-family*
              |     |                      address-family     |     +--rw maximum-routes  |       l3vpn-svc:address-family
              |     |     |  +--rw address-family* [af] neighbor*
              |     |     |  |       inet:ip-address
              |     |     |  +--rw af                address-family multihop?
              |     |     |  |       uint8
              |     |     |  +--rw maximum-routes?   uint32 security
              |     |     |  |  +--rw node-ie-profile?        leafref auth-key?   string
              |     |     |  +--rw multicast {multicast}? status
              |     |     |  |  +--rw enabled? admin-enabled?   boolean
           +--rw customer-tree-flavors
              |  +--rw tree-flavor*   identityref
           +--rw rp
              +--rw rp-group-mappings     |  +--rw rp-group-mapping* [id]     |     +--rw id                  uint16  |     +--rw provider-managed  +--ro oper-status?
              |     |  +--rw enabled?     |  |          operational-type
              |       boolean     |     |  +--rw rp-redundancy? description?
              |     |     |       boolean          string
              |     |     +--rw optimal-traffic-delivery? isis {rtg-isis}?
              |     |          boolean     |  +--rw rp-address          inet:ip-address address-family*
              |     |     |  |       l3vpn-svc:address-family
              |     |     |  +--rw groups area-address      area-address
              |     |     |  +--rw group* [id] level?            isis-level
              |     |     |  +--rw id metric?           uint16
              |     |     |  +--rw (group-format) process-id?       uint16
              |              +--:(singleaddress)     |     |  +--rw group-address?
              | mode?             enumeration
              |          inet:ip-address     |              +--:(startend)     |  +--rw group-start? status
              |     |       inet:ip-address     |     +--rw group-end? admin-enabled?   boolean
              |     |     |     +--ro oper-status?
              |     |     |             operational-type
              |     |                         inet:ip-address
              +--rw rp-discovery
                 +--rw rp-discovery-type?   identityref
                 +--rw bsr-candidates     +--rw bsr-candidate-address*
                            inet:ip-address 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
              |       ...

                     Figure 10

4.  Use of the Data Model

4.1.  Multi-Domain Resource Management 13: Routing Tree Structure

6.3.2.3.  Multicast

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

   The implementation model supports a single type of L3VPN services which span across
   administratively separated domains (i.e., that are under tree (Any-Source Multicast (ASM),
   Source-Specific Multicast (SSM), or bidirectional).

   When ASM is used, the
   administration model supports the configuration of different management systems rendez-vous
   points (RPs).  RP discovery may be 'static', 'bsr-rp', or controllers)
   requires some network resources 'auto-rp'.
   When set to be synchronized between systems.
   Particularly, there are two resources that must be orchestrated and
   manage 'static', RP to avoid asymmetric (non-functional) configuration, or the
   usage multicast grouping mapping MUST be
   configured as part of unavailable resources.  For example, RTs shall the 'rp-group-mappings' container.  The RP MAY
   be
   synchronized between PEs. a provider node or a customer node.  When every PE the RP is controlled by the same
   management system, RT allocation can be performed by the system.  In
   cases where a customer
   node, the service spans across multiple management systems,
   this task of allocating RTs has to RP address must be aligned across the domains,
   therefore, configured using the service 'rp-address' leaf
   otherwise no RP address is needed.

   The 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 supports RP redundancy through the same RD 'rp-redundancy' leaf.
   How the redundancy is achieved is out of scope and IP prefixes being exported by different PE
   routers.

5.  Relation with other Yang Models

   The L3NM model, aimed at managing is up to the L3VPN Services in
   implementation.

   When a Service
   Provider Network controller/orchestrator has relations with other
   Yang modules.

5.1.  Relation with L3SM

   [RFC8299] defines particular VPN using ASM requires a L3VPN Service YANG data Model (L3SM) that more optimal traffic
   delivery, 'optimal-traffic-delivery' can be
   used for communication between customers and VPN service providers.
   Hence, the model provides inputs set.  When set to 'true',
   the Network Operator to deliver
   such service implementation must use any mechanism to provide a more optimal
   traffic delivery for the customer.  Hence, some parts  Anycast is one of the model can mechanisms
   to enhance RPs redundancy, resilience against failures, and to
   recover from failures quickly.

   For redundancy purposes, Multicast Source Discovery Protocol (MSDP)
   may be
   directly mapped into L3NM.

   o  Routing protocols requested by enabled and used to share the client at PE-CE interface.  In
      sake state about sources between
   multiple RPs.  The purpose of alignment, MSDP in this context is to enhance the same protocols are supported.

5.2.  Relation with Network Topology

   The L3NM model manages VPN Services running over Service Provider
   Backbone network.  The set
   robustness of nodes over which it is possible to
   deploy a L3 VPN Service MAY be part of the topology contained in an
   ietf-network module.

5.3.  Relation with Device Models

   Creating services in the l3vpn-ntw module will will lead at some
   point to the configuration of devices.  Hence, it is foreseen that
   the data for the device yang modules will be derived partially from
   the L3NM vpn-service container.  Note that L3NM is NOT a device
   model.

6.  L3VPN Examples

6.1.  4G VPN Provissioning Example

   The L3VPN service defined in this draft provides a multipoint, routed
   service to the customer over an IP/MPLS core.  The L3VPNs are widely
   used to deploy 3G/4G, fixed and enterprise services principally due
   to the fact that several traffic discrimination policies can multicast service.  MSDP may be
   applied in the network to transport and guarantee the right SLAs to
   the mobile customers.

   As it is shown in the Figure 11, commonly the eNODEB (CE) is directly
   connected to the access routers (DCSG) of the mobile backhaul and
   their logical interfaces (one or many according to the Service type)
   are configured on Non-
   RP routers, which is useful in a VPN domain that transport the packets to the mobile core
   platforms.

                                                        +--------------+
           +------+    +-----+    +-----+    +-----+ does not support
   multicast sources, but does support multicast transit.

   module: ietf-l3vpn-ntw
     +--rw l3vpn-ntw
      +--rw vpn-profiles
      |  Platforms  ...
       +--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 vpn-network-accesses
              |
           |eNODEB|--/-|  PE |----|  P  |----|  PE |----|  (SGW/MME)  ...
              +--rw multicast {l3vpn-svc:multicast}?
              |
           +------+    +-----+    +-----+    +-----+  +--rw enabled?       boolean
              |     ...  +--rw tree-flavor*   identityref
              |
                                                        +--------------+

                    Figure 11: Mobile Backhaul Example

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

   Create VPN Service
   <vpn-services>
       <vpn-service>
         <vpn-id>1</vpn-id>
         <customer-name>4G</customer-name>
         <vpn-service-topology>hub-spoke</vpn-service-topology>
         <description>4G</description>
       </vpn-service>
     </vpn-services>
   </l3vpn-ntw>

                       Figure 12: Create VPN Service

   Create VPN Node: For this type  +--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 14: Multicast Tree Structure

6.3.3.  Concept of service the VPN Node is equivalent 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 VRF PNC can identify
   RTs and RDs to be configured in the physical device.

   <vpn-nodes>
     <vpn-node>
       <vpn-node-id>1</vpn-node-id>
       <ne-id>10.0.0.1</ne-id>
       <autonomous-system>65000</autonomous-system>
       <description>4G</description>
       <router-id>10.0.0.1</router-id>
       <address-family>ipv4</address-family>
       <node-role>any-to-any-role</node-role>
       <rd>1:1</rd>
     </vpn-node>
   </vpn-nodes>

                        Figure 13: Create VPN Node

   Create VPN Network Access

 <vpn-network-accesses>
 <vpn-network-access>
   <vpn-network-access-id>1/1/1</vpn-network-access-id>
   <description>4G</description>
   <status>
     <admin-enabled>true</admin-enabled>
   </status>
   <vpn-network-access-type>point-to-point</vpn-network-access-type>
   <ip-connection>
     <ipv4>
       <address-allocation-type>static-address</address-allocation-type>
       <static-addresses>
         <primary-address>1</primary-address>
         <address>
           <address-id>1</address-id>
           <provider-address>192.168.0.1</provider-address>
           <customer-address>192.168.0.2</customer-address>
           <prefix-length>30</prefix-length>
         </address>
       </static-addresses>
     </ipv4>
   </ip-connection>
   <routing-protocols>
     <routing-protocol>
       <id>1</id>
       <type>direct</type>
     </routing-protocol>
   </routing-protocols>
 </vpn-network-access>
 </vpn-network-accesses>

                   Figure 14: Create VPN Network Access

7.  Yang Module

 <CODE BEGINS> file "ietf-l3vpn-ntw@2019-11-17.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;
  }
  import ietf-yang-types {
   prefix yang;
  }
  import ietf-netconf-acm {
   prefix nacm;
  }
  import ietf-routing-types {
     prefix rt-types;
  }
  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:    Oscar Gonzalez de Dios
                  <mailto:oscar.gonzalezdedios@telefonica.com>
        Editor:    Alejandro Aguado
                  <mailto:alejandro.aguado_martin@nokia.com>
        Editor:    Victor Lopez
                  <mailto:victor.lopezalvarez@telefonica.com>
        Editor:    Daniel Voyer
                  <mailto:daniel.voyer@bell.ca>
        Editor:    Luis Angel Munoz
                  <mailto:luis-angel.munoz@vodafone.com>
    ";

    description
    "This YANG module defines a generic network-oriented VRF.

6.3.4.  Underlay Transport

   The model allows to indicate a preference for the management of Layer 3 VPNs in underlay transport
   technology when activating a Service Provider
    backbone network.
    Copyright (c) 2019 IETF Trust and the persons identified as
    authors of the code.  All rights reserved.

    Redistribution and use L3VPN service.  This preference is
   especially useful in source and binary forms, networks with or
    without modification, is permitted pursuant to, multiple domains and subject to
    the license terms contained in, the Simplified BSD License set
    forth 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 Section 4.c of the IETF Trust's Legal Provisions
    Relating to IETF Documents
    (https://trustee.ietf.org/license-info). future.

   This version document does not make any assumption about the exact definition
   of this YANG module these profiles.  How such profiles are defined is part of RFC XXXX
    (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
    for full legal notices. deployment-
   specific.

7.  L3NM Module Tree Structure

   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 (RFC 2119) (RFC 8174) when, and only when,
    they appear L3NM Module Tree Structure is depicted in all capitals, as shown here.";

    revision 2019-11-17 {
     description
     "Network centric hierarchy. Customer unused parameters prunned.
     Site removal";
     reference
       "draft-ietf-opsawg-l3sm-l3nm-01";
     }

  revision 2019-09-13 {
   description
   "Initial document. The document as a whole is based on L3SM
   module, defined in RFC 8299, modified to fit the requirements
   of the platforms at the network layer.";
   reference
     "RFC 8049.";
   }
  /* Features */
  feature cloud-access {
   description
   "Allows the VPN to connect to a CSP.";
   }
  feature multicast {
   description
   "Enables multicast capabilities in a VPN.";
  }
  feature ipv4 {
   description
   "Enables IPv4 support in a VPN.";
  }
  feature ipv6 {
   description
   "Enables IPv6 support in a VPN.";
  }
  feature lan-tag {
   description
   "Enables LAN Tag support in a VPN Policy filter.";
  }
  feature carrierscarrier {
   description
   "Enables support of CsC.";
  }
  feature extranet-vpn {
   description
   "Enables support of extranet VPNs.";
  }
  feature encryption {
   description
   "Enables support of encryption.";
  }
  feature qos {
   description
   "Enables support of classes of services.";
  }
  feature qos-custom {
   description
   "Enables support of the custom QoS profile.";
  }
  feature rtg-bgp {
   description
   "Enables support of the BGP routing protocol.";
  }
  feature rtg-rip {
   description
   "Enables support of the RIP routing protocol.";
  }
  feature rtg-ospf {
   description
   "Enables support of the OSPF routing protocol.";
  }
  feature rtg-ospf-sham-link {
   description
   "Enables support of OSPF sham links.";
  }
  feature rtg-vrrp {
   description
   "Enables support of the VRRP routing protocol.";
  }
  feature fast-reroute {
   description
   "Enables support of Fast Reroute.";
  }
  feature bfd {
   description
   "Enables support of BFD.";
  }
  feature bearer-reference {
   description
   "Enables support of the 'bearer-reference' access constraint.";
  }
  feature target-sites {
   description
   "Enables support of the 'target-sites' match flow parameter.";
  }
 feature input-bw {
   description
   "Enables support of the 'input-bw' limit.";
  }
 feature dot1q  {
   description
   "Enables support of the 'dot1q' encapsulation.";
  }
 feature qinq  {
   description
   "Enables support of the 'qinq' encapsulation.";
  }
 feature qinany  {
   description
   "Enables support of the 'qinany' encapsulation.";
  }
  feature vxlan  {
   description
   "Enables support of the 'vxlan' encapsulation.";
  }

  /* Typedefs */
  typedef svc-id {
   type string;
   description
   "Defines a type of service component identifier.";
  }
  typedef template-id {
   type string;
   description
   "Defines a type of service template identifier.";
  }
  typedef address-family {
   type enumeration {
    enum ipv4 {
     description
     "IPv4 address family.";
    }
    enum ipv6 {
     description
     "IPv6 address family.";
    }
    enum ipv4/ipv6 {
     description
     "IPv4/IPv6 address family.";
    }
   }
   description
   "Defines a type for the address family.";
  }

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

   typedef Figure 15.

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]
   |     |  +--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]
       +--rw service-status
       |  +--rw admin
       |  |  +--rw status?      operational-type {
    type enumeration {
      enum "up" {
        value 0;
        description "Operational status UP.";
      }
      enum "down" {
       value 1;
       description "Operational status DOWN";
      }
      enum "unknown" {
       value 2;
       description "Operational
       |  |  +--rw timestamp?   yang:date-and-time
       |  +--ro ops
       |     +--ro status?      operational-type
       |     +--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    string
       |     +--rw rd?              rt-types:route-distinguisher
       |     +--rw vpn-targets
       |        +--rw vpn-target* [id]
       |        |  +--rw id                   int8
       |        |  +--rw route-targets* [route-target]
       |        |  |  +--rw route-target
       |        |  |          rt-types:route-target
       |        |  +--rw route-target-type
       |        |          rt-types:route-target-type
       |        +--rw vpn-policies
       |           +--rw import-policy?   leafref
       |           +--rw export-policy?   leafref
       +--rw underlay-transport
       |  +--rw type?   protocols-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?
           |       rt-types:route-distinguisher
           +--rw vpn-targets
           |  +--rw vpn-target* [id]
           |  |  +--rw id                   int8
           |  |  +--rw route-targets* [route-target]
           |  |  |  +--rw route-target
           |  |  |          rt-types:route-target
           |  |  +--rw route-target-type
           |  |          rt-types:route-target-type
           |  +--rw vpn-policies
           |     +--rw import-policy?   leafref
           |     +--rw export-policy?   leafref
           +--rw status UNKNOWN";
      }
    }
    description
   "This is a read-only attribute used to determine the
           |  +--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 port-id?
           |     |       l3vpn-svc:svc-id
           |     +--rw description?               string
           |     +--rw status of a particular element";
   }

  /* Identities */
  identity site-network-access-type {
   description
   "Base identity for site-network-access type.";
  }
  identity point-to-point {
   base site-network-access-type;
   description
   "Identity for point-to-point connection.";
  }
  /* Extension */
  identity pseudowire {
   base site-network-access-type;
   description
   "Identity for pseudowire connection.";
  }
  /* End of Extension */
  identity multipoint {
   base site-network-access-type;
   description
   "Identity for multipoint connection.
   Example: Ethernet broadcast segment.";
  }
  identity customer-application {
   description
   "Base identity for customer application.";
  }
  identity web {
   base customer-application;
   description
   "Identity for Web application (e.g., HTTP, HTTPS).";
  }
  identity mail {
   base customer-application;
   description
   "Identity for mail application.";
  }
  identity file-transfer {
   base customer-application;
   description
   "Identity for file transfer application (e.g., FTP, SFTP).";
  }
  identity database {
   base customer-application;
   description
   "Identity for database application.";
  }
  identity social {
   base customer-application;
   description
   "Identity for social-network application.";
  }
  identity games {
   base customer-application;
   description
   "Identity for gaming application.";
  }
  identity p2p {
   base customer-application;
   description
   "Identity for peer-to-peer application.";
  }
  identity network-management {
   base customer-application;
   description
   "Identity for management application
   (e.g., Telnet, syslog, SNMP).";
  }
  identity voice {
   base customer-application;
   description
   "Identity for voice application.";
  }
  identity video {
   base customer-application;
   description
   "Identity
           |     |  +--rw admin-enabled?   boolean
           |     |  +--ro oper-status?     operational-type
           |     +--rw vpn-network-access-type?   identityref
           |     +--rw connection
           |     |  +--rw encapsulation-type?   identityref
           |     |  +--rw logical-interface
           |     |  |  +--rw peer-reference?   uint32
           |     |  +--rw tagged-interface
           |     |  |  +--rw type?                identityref
           |     |  |  +--rw dot1q-vlan-tagged {dot1q}?
           |     |  |  |  +--rw tag-type?   identityref
           |     |  |  |  +--rw cvlan-id?   uint16
           |     |  |  +--rw priority-tagged
           |     |  |  |  +--rw tag-type?   identityref
           |     |  |  +--rw qinq {qinq}?
           |     |  |  |  +--rw tag-type?   identityref
           |     |  |  |  +--rw svlan-id    uint16
           |     |  |  |  +--rw cvlan-id    uint16
           |     |  |  +--rw qinany {qinany}?
           |     |  |  |  +--rw tag-type?   identityref
           |     |  |  |  +--rw svlan-id    uint16
           |     |  |  +--rw vxlan {vxlan}?
           |     |  |     +--rw vni-id       uint32
           |     |  |     +--rw peer-mode?   identityref
           |     |  |     +--rw peer-list* [peer-ip]
           |     |  |        +--rw peer-ip    inet:ip-address
           |     |  +--rw bearer
           |     |     +--rw bearer-reference?   string
           |     |     |       {l3vpn-svc:bearer-reference}?
           |     |     +--rw pseudowire
           |     |     |  +--rw vcid?      uint32
           |     |     |  +--rw far-end?   union
           |     |     +--rw vpls
           |     |        +--rw vcid?      union
           |     |        +--rw far-end?   union
           |     +--rw ip-connection
           |     |  +--rw ipv4 {l3vpn-svc:ipv4}?
           |     |  |  +--rw address-allocation-type?
           |     |  |  |       identityref
           |     |  |  +--rw provider-dhcp
           |     |  |  |  +--rw provider-address?
           |     |  |  |  |       inet:ipv4-address
           |     |  |  |  +--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: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]
           |     |  |        +--rw address-id          string
           |     |  |        +--rw provider-address?
           |     |  |        |       inet:ipv4-address
           |     |  |        +--rw customer-address?
           |     |  |        |       inet:ipv4-address
           |     |  |        +--rw prefix-length?      uint8
           |     |  +--rw ipv6 {l3vpn-svc:ipv6}?
           |     |  |  +--rw address-allocation-type?
           |     |  |  |       identityref
           |     |  |  +--rw provider-dhcp
           |     |  |  |  +--rw provider-address?
           |     |  |  |  |       inet:ipv6-address
           |     |  |  |  +--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 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)?
           |        |        +--:(standard)
           |        |        |  +--rw profile?     leafref
           |        |        |  +--rw direction?   identityref
           |        |        +--:(custom)
           |        |           +--rw classes
           |        |                   {l3vpn-svc:qos-custom}?
           |        |              +--rw class* [class-id]
           |        |                 +--rw class-id
           |        |                 |       string
           |        |                 +--rw direction?
           |        |                 |       identityref
           |        |                 +--rw rate-limit?
           |        |                 |       decimal64
           |        |                 +--rw latency
           |        |                 |  +--rw (flavor)?
           |        |                 |     +--:(lowest)
           |        |                 |     |  +--rw use-lowest-latency?
           |        |                 |     |          empty
           |        |                 |     +--:(boundary)
           |        |                 |        +--rw jitter-boundary?
           |        |                 |                uint16
           |        |                 +--rw jitter
           |        |                 |  +--rw (flavor)?
           |        |                 |     +--:(lowest)
           |        |                 |     |  +--rw use-lowest-jitter?
           |        |                 |     |          empty
           |        |                 |     +--:(boundary)
           |        |                 |        +--rw latency-boundary?
           |        |                 |                uint32
           |        |                 +--rw bandwidth
           |        |                    +--rw guaranteed-bw-percent
           |        |                    |       decimal64
           |        |                    +--rw end-to-end?
           |        |                            empty
           |        +--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 15

8.  Sample Uses of the L3NM Data Model

8.1.  Enterprise L3 VPN Services

   Enterprise L3VPNs are one of the most demanded services for video conference application.";
  }
  identity embb {
   base customer-application;
   description
   "Identity 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 an enhanced Mobile Broadband (eMBB)
   application.  Note 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 eMBB application demands existing customer VPN can
   benefit of using L3NM, by creation of workflows that either prune or
   add nodes as required from the network performance with 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 wide variety 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
   characteristics, such Multicast services

   Multicast services over L3VPN can be implemented either using dual
   PIM MVPNs (also known as data rate, latency,
   loss rate, reliability, 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 many other parameters.";
 }
 identity urllc {
   base customer-application;
   description
   "Identity for an Ultra-Reliable
   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 Low Latency
   Communications (URLLC) application.  Note PIM
   sparse mode as the data plane.  The PIM state information is
   maintained between the PE routers using the same architecture that a
   URLLC application demands network performance
   with a wide variety of characteristics, is
   used for unicast VPNs.

   On the other hand, Draft Rosen has limitations such as latency,
   reliability, and many other parameters.";
  }
  identity mmtc {
    base customer-application;
    description
    "Identity reduced
   options for a massive Machine Type
    Communications (mMTC) application.  Note that an
    mMTC application demands network performance
    with a wide variety transport, control plane scalability, availability,
   operational inconsistency and the need of characteristics, such maintaining state in the
   backbone.  Because of this, ng-MNPN is the architectural model that
   has been taken as data
    rate, latency, loss rate, reliability, and many
    other parameters.";
  }
  identity address-allocation-type {
   description
   "Base identity for address-allocation-type for PE-CE link.";
  }
  identity provider-dhcp { the base address-allocation-type;
   description
   "Provider network provides DHCP for implementing multicast service on
   L3VPN.  In this scenario, BGP auto discovery is used to customer.";
  }
  identity provider-dhcp-relay {
   base address-allocation-type;
   description
   "Provider network provides DHCP relay service 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 Provissioning Example

   L3VPNs are widely used to customer.";
  }
  identity provider-dhcp-slaac {
   base address-allocation-type;
   description
   "Provider deploy 3G/4G, fixed, and enterprise
   services mainly because several traffic discrimination policies can
   be applied within the network provides DHCP service to customer,
   as well as SLAAC.";
  }
  identity static-address {
   base address-allocation-type;
   description
   "Provider-to-customer addressing deliver to the mobile customers a
   service that meets the SLA requiremets.

   As it is static.";
  }
  identity slaac {
   base address-allocation-type;
   description
   "Use IPv6 SLAAC.";
  }
  identity site-role {
   description
   "Base identity for site type.";
  }
  identity any-to-any-role {
   base site-role;
   description
   "Site shown in the Figure 16, typically, an any-to-any IP VPN.";
  }
  identity spoke-role {
   base site-role;
   description
   "Spoke site in a Hub-and-Spoke IP VPN.";
  }
  identity hub-role {
   base site-role;
   description
   "Hub site 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 Hub-and-Spoke IP VPN.";

  }
  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 that transports the packets to the mobile
   core platforms.  In this example, a 'vpn-node' is created with each other.";
  }
  identity multicast-tree-type {
   description
   "Base identity for multicast tree type.";
  }
  identity ssm-tree-type {
   base multicast-tree-type;
   description
   "Identity for SSM tree type.";
  }
  identity asm-tree-type {
   base multicast-tree-type;
   description
   "Identity for ASM tree type.";
  }
  identity bidir-tree-type {
   base multicast-tree-type;
   description
   "Identity for bidirectional tree type.";
  }
  identity multicast-rp-discovery-type {
   description
   "Base identity for RP discovery type."; 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 16: Mobile Backhaul Example

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

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

   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"
       ]
     }
  identity auto-rp {
   base multicast-rp-discovery-type;
   description
   "Base identity for Auto-RP discovery type.";
   }
  identity static-rp {
   base multicast-rp-discovery-type;
   description
   "Base identity for static type.";

                       Figure 17: Create VPN Service

   Second: Create a VPN Node as depicted in Figure 18.  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"
           }
  identity bsr-rp {
   base multicast-rp-discovery-type;
   description
   "Base identity for BSR discovery type.";
         }
  identity routing-protocol-type {
   description
   "Base identity for routing protocol type.";
       ]
     }
  identity ospf {
   base routing-protocol-type;
   description
   "Identity for OSPF protocol type.";
   }
  identity bgp {
   base routing-protocol-type;
   description
   "Identity for BGP protocol type.";

                        Figure 18: 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 differentiante the traffic between: Sync and data
   (Figure 19).

   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"
             ]
           }
  identity static {
   base routing-protocol-type;
   description
   "Identity for static routing protocol type.";
         }
  identity rip {
   base routing-protocol-type;
   description
   "Identity for RIP protocol type.";
       ]
     }
  identity vrrp {
   base routing-protocol-type;
   description
   "Identity for VRRP protocol type.
   This
   }

                   Figure 19: 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 to be used when LANs are
   directly connected to the multicast source.  The signaling between PE routers.";
  }
  identity direct {
   base routing-protocol-type;
   description
   "Identity for direct protocol type.";
  }
  identity protocol-type {
   description
   "Base identity
   and CE is achieved using BGP.  Also, RP is statically configured for protocol field type.";
  }
  identity tcp {
   base protocol-type;
   description
   "TCP protocol type.";
  }
  identity udp {
   base protocol-type;
   description
   "UDP protocol type.";
  }

  identity icmp {
   base protocol-type;
   description
   "ICMP protocol type.";
  }
  identity icmp6 {
   base protocol-type;
   description
   "ICMPv6 protocol type.";
  }
  identity gre
   a multicast group.

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

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

                "vpn-services": {
   base protocol-type;
   description
   "GRE protocol type.";
  }
  identity ipip
                       "vpn-service": {
   base protocol-type;
   description
   "IP-in-IP protocol type.";
                         "vpn-id": "Multicast_IPTV",
                         "customer-name": "310",
                         "vpn-service-topology": "hub-spoke",
                         "description": "Multicast IPTV VPN service"
                       }
  identity hop-by-hop {
   base protocol-type;
   description
   "Hop-by-Hop IPv6 header type.";
                   }
  identity routing

      Figure 21: 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 22).  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": {
   base protocol-type;
   description
   "Routing IPv6 header type.";
  }
  identity esp
                   "l3vpn-svc:hub-role"
                 },
                 "rd": "3816:31050202",
                 "multicast": {
   base protocol-type;
   description
   "ESP header type.";

  }
  identity ah
                   "enabled": "true",
                   "rp": {
   base protocol-type;
   description
   "AH header type.";
  }
  identity vpn-policy-filter-type
                     "rp-group-mappings": {
   description
   "Base identity for VPN Policy filter type.";
  }
  identity ipv4
                       "rp-group-mapping": {
    base vpn-policy-filter-type;
    description
    "Identity for IPv4 Prefix filter type.";
  }
  identity ipv6
                         "id": "1",
                         "rp-address": "172.19.48.17",
                         "groups": {
    base vpn-policy-filter-type;
    description
    "Identity for IPv6 Prefix filter type.";
 }
  identity lan
                           "group": {
    base vpn-policy-filter-type;
    description
    "Identity for LAN Tag filter type.";
                             "id": "1",
                             "group-address": "239.130.0.0/15"
                           }

  identity qos-profile-direction {
   description
   "Base identity for QoS profile direction.";
                         }

  identity site-to-wan {
    base qos-profile-direction;
    description
    "Identity for Site-to-WAN direction.";
                       }
  identity wan-to-site
                     },
                     "rp-discovery": {
    base qos-profile-direction;
    description
    "Identity for WAN-to-Site direction.";
  }
  identity both
                       "rp-discovery-type": {
    base qos-profile-direction;
    description
    "Identity for both WAN-to-Site direction
    and Site-to-WAN direction.";
                         "l3vpn-svc:static-rp"
                       }
  /* Extended Identities */

  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 for the VLAN type.";
                 }

   identity eth-inf-type {
     description
       "Identity
               ]

   Figure 22: Create Multicast VPN Node (Excerpt of the Ethernet interface type.";
   }

   identity tagged {
     base eth-inf-type;
     description
       "Identity of Message Request
                                   Body)

   Finally, create the tagged interface type.";
   }

   identity untagged {
     base eth-inf-type;
     description
       "Identity of VPN Network Access with Multicast enabled (see
   the untagged interface type.";
   }

   identity lag {
     base eth-inf-type;
     description
       "Identity excerpt of the LAG interface type.";
   }
   identity bearer-inf-type request message body shown in Figure 23)

             "vpn-network-access": {
     description
       "Identity for the bearer interface type.";
   }

   identity port-id
               "vpn-network-access-id": "1/1/1",
               "description": "Connected_to_source",
               "status": {
     base bearer-inf-type;
     description
       "Identity for the priority-tagged interface.";
   }

   identity lag-id "admin-enabled": "true" },
               "vpn-network-access-type": {
     base bearer-inf-type;
     description
       "Identity for the priority-tagged interface.";
   }

   identity tagged-inf-type
                 "l3vpn-svc:point-to-point"
               },
               "ip-connection": {
     description
       "Identity for the tagged interface type.";
   }

   identity priority-tagged
                 "ipv4": {
     base tagged-inf-type;
     description
       "Identity for the priority-tagged interface.";
   }

   identity qinq
                   "address-allocation-type": {
     base tagged-inf-type;
     description
       "Identity for the QinQ tagged interface.";
   }

   identity dot1q
                     "l3vpn-svc:static-address"
                   },
                   "static-addresses": {
     base tagged-inf-type;
     description
       "Identity for the dot1Q VLAN tagged interface.";
   }

   identity qinany
                     "primary-address": "1",
                     "address": {
     base tagged-inf-type;
     description
       "Identity for the QinAny tagged interface.";
                       "address-id": "1",
                       "provider-address": "172.19.48.1",
                       "prefix-length": "30"
                     }

   identity vxlan {
     base tagged-inf-type;
     description
       "Identity for the VXLAN tagged interface.";
                   }

   identity tag-type {
     description
       "Base identity from which all tag types are derived.";
                 }

   identity c-vlan
               },
               "routing-protocols": {
     base tag-type;
     description
       "A CVLAN tag, normally using the 0x8100 Ethertype.";
                 "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"
                   }

   identity s-vlan
                 }
               },
               "service": {
     base tag-type;
     description
       "An SVLAN tag.";
                 "multicast": {
                   "multicast-site-type": "source-only",
                   "multicast-address-family": { "ipv4": "true" },
                   "protocol-type": "router"
                 }

   identity c-s-vlan
               }
             }

   Figure 23: 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 {
     base tag-type;
     description
       "Using both a CVLAN tag and an SVLAN tag.";
  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";
  }

   identity vxlan-peer-mode
  import ietf-yang-types {
     description
       "Base identity for the VXLAN peer mode.";
    prefix yang;
    reference
      "Section 3 of RFC 6991";
  }

   identity static-mode
  import ietf-netconf-acm {
     base vxlan-peer-mode;
     description
       "Identity for VXLAN access in the static mode.";
    prefix nacm;
    reference
      "RFC 8341: Network Configuration Access Control Model";
  }

   identity bgp-mode
  import ietf-routing-types {
     base vxlan-peer-mode;
     description
       "Identity
    prefix rt-types;
    reference
      "RFC 8294: Common YANG Data Types for VXLAN access by BGP EVPN learning."; the Routing Area";
  }

   identity bw-direction
  import ietf-l3vpn-svc {
     description
       "Identity
    prefix l3vpn-svc;
    reference
      "RFC 8299: YANG Data Model for the bandwidth direction."; L3VPN Service Delivery";
  }

   identity input-bw
  import ietf-packet-fields {
     base bw-direction;
     description
       "Identity
    prefix packet-fields;
    reference
      "RFC 8519: YANG Data Model for the input bandwidth."; Network Access
                 Control Lists (ACLs)";
  }
   identity output-bw {
     base bw-direction;

  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
       "Identity
    "This YANG module defines a generic network-oriented model
     for the output bandwidth.";
   }

   identity bw-type {
     description
       "Identity configuration of Layer 3 Virtual Private Networks.
     Copyright (c) 2020 IETF Trust and 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 persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is applicable permitted pursuant to, and subject to
        all
     the site network accesses within license terms contained in, the site.";
   }

   identity bw-per-svc 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-03-09 {
     base bw-type;
    description
       "Bandwidth is per
      "Initial revision.";
    reference
      "RFC XXXX: A Layer 3 VPN service."; Network YANG Model";
  }

  /* Groupings Features */
  grouping multicast-rp-group-cfg {
   choice group-format {
    mandatory true;
    case singleaddress {
     leaf group-address

  feature msdp {
      type inet:ip-address;
    description
      "A single multicast group address.";
     }
      "This feature indicates that msdp capabilities
       are supported by the VPN.";
  }
    case startend {
     leaf group-start

  feature rtg-isis {
      type inet:ip-address;
    description
      "The first multicast group address in
      "This features indicates the multicast group address range."; support of the ISIS
       routing protocol.";
  }
     leaf group-end

  feature rtg-ospf-sham-link {
      type inet:ip-address;
    description
      "The last multicast group address in
      "This feature indicates the multicast group address range.";
     } support of OSPF sham links.";
  }

  feature input-bw {
    description
    "Choice for multicast group format.";
      "This feature indicates the support of
       the 'input-bw' limit.";
  }

  feature dot1q {
    description
      "This grouping defines multicast group or
   multicast groups for RP-to-group mapping."; feature indicates the support of
       the 'dot1q' encapsulation.";
  }
  grouping vpn-service-multicast {
   container multicast {
    if-feature multicast;
    leaf enabled

  feature qinq {
     type boolean;
     default false;
    description
     "Enables multicast.";
      "This feature indicates the support of
       the 'qinq' encapsulation.";
  }
    container customer-tree-flavors {
     leaf-list tree-flavor {
      type identityref

  feature qinany {
       base multicast-tree-type;
      }
    description
       "Type
      "This feature indicates the support of tree to be used.";
       the 'qinany' encapsulation.";
  }

  feature vxlan {
    description
     "Type
      "This feature indicates the support of trees used by customer.";
       the 'vxlan' encapsulation.";
  }
    container rp

  /* Typedefs */

  typedef protocols-type {
     container rp-group-mappings
    type enumeration {
      list rp-group-mapping
      enum GRE {
       key id;
       leaf id
        value 0;
        description
          "Transport based on GRE.";
      }
      enum LDP {
        type uint16;
        value 1;
        description
        "Unique identifier for the mapping.";
          "Transport based on LDP.";
      }
       container provider-managed
      enum BGP {
        leaf enabled
        value 2;
        description
          "Transport based on BGP.";
      }
      enum SR {
         type boolean;
         default false;
        value 3;
        description
         "Set to true if the Rendezvous Point (RP)
         must be a provider-managed node.  Set to false
         if it is a customer-managed node.";
          "Transport based on Segment Routing (SR)";
      }
        leaf rp-redundancy
      enum SR-TE {
         type boolean;
         default false;
        value 4;
        description
         "If true, a redundancy mechanism
          "Transport based on SR for the RP
         is required."; Traffic Engineering.";
      }
        leaf optimal-traffic-delivery
      enum RSVP-TE {
         type boolean;
         default false;
         description
         "If true, the SP must ensure that
         traffic uses an optimal path.  An SP may use
         Anycast RP or RP-tree-to-SPT switchover
         architectures.";
        }
        value 5;
        description
        "Parameters
          "Transport based on RSVP for a provider-managed RP."; Traffic Engineering";
      }
       leaf rp-address {
        when "../provider-managed/enabled = 'false'"
      enum unknown {
        value 6;
        description
         "Relevant
          "Transport UNKNOWN";
      }
    }
    description
      "These attributes are used to identify underlying
       protocols when the RP is not provider-managed."; activating an L3VPN service.";
  }

  typedef area-address {
    type inet:ip-address;
          mandatory true; string {
      pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}';
    }
    description
        "Defines
      "This type defines the area address of the RP.
        Used if the RP is customer-managed."; format.";
  }
       container groups

  typedef isis-level {
        list group
    type enumeration {
         key id;
         leaf id
      enum level1 {
          type uint16;
        value 0;
        description
          "Identifier for the group.";
          "ISIS level 1";
      }
         uses multicast-rp-group-cfg;
      enum level2 {
        value 1;
        description
         "List of multicast groups.";
          "ISIS level 2";
      }
      enum level1-2 {
        value 2;
        description
        "Multicast groups associated with the RP.";
          "ISIS level 1 and 2";
      }
       description
       "List of RP-to-group mappings.";
    }
    description
      "RP-to-group mappings parameters.";
      "Defines the ISIS level for interface and system.";
  }
     container rp-discovery {
      leaf rp-discovery-type

  typedef ie-type {
    type identityref enumeration {
        base multicast-rp-discovery-type;
        }
       default static-rp;
      enum import {
        value 0;
        description
       "Type of RP discovery used.";
          "Import a routing profile.";
      }
      container bsr-candidates {
        when "derived-from-or-self(../rp-discovery-type, "+
            "'l3vpn-ntw:bsr-rp')"
      enum export {
        value 1;
        description
        "Only applicable if discovery type
        is BSR-RP.";
          "Export a routing profile.";
      }
       leaf-list bsr-candidate-address
      enum both {
        type inet:ip-address;
        value 2;
        description
         "Address of BSR candidate.";
          "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
       "Container for List of Customer
       BSR candidate's addresses.";
          "Operational status UP/Enabled.";
      }
      enum down {
        value 1;
        description
      "RP discovery parameters.";
          "Operational status DOWN/Disabled.";
      }
      enum unknown {
        value 2;
        description
     "RP parameters.";
          "Operational status UNKNOWN.";
      }
    }
    description
    "Multicast global parameters for
      "This attribute is used to determine the VPN service.";
       status of a particular element.";
  }

  /* Identities */

  identity vpn-topology {
    description
   "Grouping
      "Base identity for multicast VPN definition."; topology.";
  }
  grouping vpn-service-mpls {
   leaf carrierscarrier

  identity any-to-any {
    if-feature carrierscarrier;
     type boolean;
     default false;
    base vpn-topology;
    description
     "The
      "Identity for any-to-any VPN is using CsC, and so MPLS is required."; topology.";
  }

  identity hub-spoke {
    base vpn-topology;
    description
   "Grouping
      "Identity for MPLS CsC definition."; Hub-and-Spoke VPN topology.";
  }
  grouping operational-requirements {
    leaf requested-site-start

  identity hub-spoke-disjoint {
     type yang:date-and-time;
    base vpn-topology;
    description
      "Optional leaf indicating requested date and
      time when the service at a particular site is
      expected to start.";
      "Identity for Hub-and-Spoke VPN topology
       where Hubs cannot communicate with each other.";
  }
   leaf requested-site-stop

  identity custom {
     type yang:date-and-time;
    base vpn-topology;
    description
      "Optional leaf indicating requested date and
      time when
      "Identity for CUSTOM VPN topology
       where Hubs can act as Spoke for certain part of
       the service at a particular site is
      expected to stop.";
   }
   description
   "This grouping defines some operational
   parameters."; network or Spokes as Hubs.";
  }
  grouping operational-requirements-ops {
    leaf actual-site-start

  identity isis {
     type yang:date-and-time;
     config false;
    base l3vpn-svc:routing-protocol-type;
    description
      "Optional leaf indicating actual date and
      time when the service at a particular site
      actually started.";
      "Identity for ISIS protocol type.";
  }
   leaf actual-site-stop

  identity pseudowire {
    type yang:date-and-time;
    config false;
      description
      "Optional leaf indicating actual date and
      time when the service at a particular site
      actually stopped.";

   }
    base l3vpn-svc:site-network-access-type;
    description
   "This grouping defines some operational
   parameters.";
      "Identity for pseudowire connections.";
  }
  grouping flow-definition {
   container match-flow {
    leaf dscp

  identity loopback {
     type inet:dscp;
    base l3vpn-svc:site-network-access-type;
    description
      "DSCP value.";
      "Identity for loopback connections.";
  }
    leaf dot1p {
     type uint8

  identity encapsulation-type {
      range "0..7";
     }
    description
     "802.1p matching.";
      "Identity for the encapsulation type.";
  }
    leaf ipv4-src-prefix

  identity untagged-int {
     type inet:ipv4-prefix;
    base encapsulation-type;
    description
      "Match on IPv4 src address.";
      "Identity for Ethernet type.";
  }
    leaf ipv6-src-prefix

  identity tagged-int {
     type inet:ipv6-prefix;
    base encapsulation-type;
    description
      "Match on IPv6 src address.";
      "Identity for the VLAN type.";
  }
    leaf ipv4-dst-prefix

  identity eth-inf-type {
     type inet:ipv4-prefix;
    description
      "Match on IPv4 dst address.";
      "Identity of the Ethernet interface type.";
  }
    leaf ipv6-dst-prefix

  identity tagged {
     type inet:ipv6-prefix;
    base eth-inf-type;
    description
     "Match on IPv6 dst address.";
      "Identity of the tagged interface type.";
  }
    leaf l4-src-port {
     type inet:port-number;
         must "current() < ../l4-src-port-range/lower-port or "+
         "current() > ../l4-src-port-range/upper-port"

  identity untagged {
    base eth-inf-type;
    description
      "If l4-src-port and l4-src-port-range/lower-port and
      upper-port are set at
      "Identity of the same time, l4-src-port
      should not overlap with l4-src-port-range."; untagged interface type.";
  }

  identity lag {
    base eth-inf-type;
    description
      "Match on Layer 4 src port.";
      "Identity of the LAG interface type.";
  }
    leaf-list target-sites
  identity bearer-inf-type {
      if-feature target-sites;
      type svc-id;
    description
      "Identify a site as traffic destination.";
      "Identity for the bearer interface type.";
  }
    container l4-src-port-range {
      leaf lower-port

  identity port-id {
      type inet:port-number;
    base bearer-inf-type;
    description
      "Lower boundary
      "Identity for port."; the priority-tagged interface.";
  }
     leaf upper-port {
      type inet:port-number;
      must ". >= ../lower-port"

  identity lag-id {
    base bearer-inf-type;
    description
       "Upper boundary
      "Identity for port.  If it
       exists, the upper boundary must be
       higher than the lower boundary."; priority-tagged interface.";
  }

  identity tagged-inf-type {
    description
      "Upper boundary
      "Identity for port."; the tagged interface type.";
  }

  identity priority-tagged {
    base tagged-inf-type;
    description
      "Match on Layer 4 src port range.  When
      only the lower-port is present, it represents
      a single port.  When both
      "Identity for the lower-port and
      upper-port are specified, it implies
      a range inclusive of both values."; priority-tagged interface.";
  }
    leaf l4-dst-port

  identity qinq {
     type inet:port-number;
          must "current() < ../l4-dst-port-range/lower-port or "+
          "current() > ../l4-dst-port-range/upper-port"
    base tagged-inf-type;
    description
      "Identity for the QinQ tagged interface.";
  }

  identity dot1q {
    base tagged-inf-type;
    description
      "If l4-dst-port and l4-dst-port-range/lower-port
      and upper-port are set at
      "Identity for the same time,
      l4-dst-port should not overlap with
      l4-src-port-range."; dot1Q VLAN tagged interface.";
  }

  identity qinany {
    base tagged-inf-type;
    description
      "Match on Layer 4 dst port.";
      "Identity for the QinAny tagged interface.";
  }
    container l4-dst-port-range {
     leaf lower-port

  identity vxlan {
      type inet:port-number;
    base tagged-inf-type;
    description
      "Lower boundary
      "Identity for port."; the VXLAN tagged interface.";
  }
     leaf upper-port

  identity tag-type {
      type inet:port-number;
      must ". >= ../lower-port"
    description
      "Base identity from which all tag types are derived.";
  }

  identity c-vlan {
    base tag-type;
    description
      "Upper boundary must be
      higher than lower boundary.";
      "A CVLAN tag, normally using the 0x8100 Ethertype.";
  }

  identity s-vlan {
    base tag-type;
    description
      "Upper boundary for port.  If it exists,
      upper boundary must be higher than lower
      boundary.";
      "An SVLAN tag.";
  }

  identity c-s-vlan {
    base tag-type;
    description
     "Match on Layer 4 dst port range.  When only
     lower-port is present, it represents a single
     port.  When
      "Using both lower-port and upper-port are
     specified, it implies a range inclusive of both
     values."; CVLAN tag and an SVLAN tag.";
  }
    leaf protocol-field {
     type union

  identity vxlan-peer-mode {
      type uint8;
      type identityref
    description
      "Base identity for the VXLAN peer mode.";
  }

  identity static-mode {
    base protocol-type;
      }
     } vxlan-peer-mode;
    description
     "Match on IPv4 protocol or IPv6 Next Header field.";
      "Identity for VXLAN access in the static mode.";
  }

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

  identity bw-direction {
    description
   "Flow definition based on criteria.";
      "Identity for the bandwidth direction.";
  }
  grouping site-service-basic {
   leaf svc-input-bandwidth
  identity input-bw {
     type uint64;
     units bps;
     mandatory true;
    base bw-direction;
    description
      "From the customer site's perspective,
      "Identity for the service input bandwidth of the connection or download
      bandwidth from the SP to the site."; bandwidth.";
  }
   leaf svc-output-bandwidth

  identity output-bw {
    type uint64;
    units bps;
    mandatory true;
    base bw-direction;
    description
      "From the customer site's perspective,
      "Identity for the service output bandwidth bandwidth.";
  }

  identity bw-type {
    description
      "Identity of the connection or upload bandwidth from the site to the SP."; type.";
  }

  identity bw-per-cos {
    base bw-type;
    description
      "Bandwidth is per Class of Service (CoS).";
  }

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

  identity bw-per-site {
    type uint16;
    units bytes;
    mandatory true;
    base bw-type;
    description
     "MTU at service level.  If the service
      "Bandwidth is IP,
     it refers to the IP MTU.  If CsC per site.  It is enabled,
     the requested 'svc-mtu' leaf will refer to the
     MPLS MTU and not applicable to
       all the IP MTU.";
   }
   description
   "Defines basic service parameters for site network accesses within a site.";
  }

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

  /* Groupings */

  grouping site-protection svc-transport-encapsulation {
    container traffic-protection underlay-transport {
    if-feature fast-reroute;
      leaf enabled type {
        type boolean;
     default false; protocols-type;
        description
      "Enables traffic protection of access link.";
          "Protocols used to deliver an L3VPN service.";
      }
      description
    "Fast Reroute service parameters for the site.";
        "";
    }
    description
   "Defines protection service parameters for a site.";
      "";
  }

  grouping site-service-mpls multicast-rp-group-cfg {
   container carrierscarrier
    choice group-format {
      mandatory true;
      case group-prefix {
    if-feature carrierscarrier;
        leaf signalling-type group-address {
          type enumeration {
     enum ldp { inet:ip-prefix;
          description
      "Use LDP as the signalling protocol
      between the PE and the CE.  In this case,
      an IGP routing protocol must also be activated.";
            "A single multicast group prefix.";
        }
     enum bgp
      }
      case startend {
        leaf group-start {
          type inet:ip-address;
          description
      "Use BGP (as per RFC 8277) as the signalling protocol
      between the PE and the CE.
      In this case, BGP must also be configured as
            "The first multicast group address in
             the routing protocol.";
      }
     }
     default bgp;
     description
     "MPLS signalling type."; multicast group address range.";
        }
        leaf group-end {
          type inet:ip-address;
          description
      "This container is used when the customer provides
      MPLS-based services.  This is only used
            "The last multicast group address in
             the case
      of CsC (i.e., a customer builds an MPLS service using
      an IP VPN to carry its traffic)."; multicast group address range.";
        }
      }
      description
      "Defines MPLS service parameters
        "Choice for a site."; multicast group format.";
    }
    description
      "This grouping site-service-qos-profile defines multicast group or
       multicast groups for RP-to-group mapping.";
  }

  grouping vpn-service-multicast {
    container qos multicast {
      if-feature qos;
    container qos-classification-policy {
     list rule {
      key id;
      ordered-by user; "l3vpn-svc:multicast";
      leaf id enabled {
        type string;
       description
       "A description identifying the
        qos-classification-policy rule.";
      }
      choice match-type { boolean;
        default match-flow;
       case match-flow {
       uses flow-definition; "false";
        description
          "Enables multicast.";
      }
       case match-application {
        leaf match-application
      leaf-list tree-flavor {
        type identityref {
          base customer-application; l3vpn-svc:multicast-tree-type;
        }
        description
          "Defines the application
          "Type of tree to match.";
        }

       }
       description
       "Choice for classification."; be used.";
      }
      container rp {
        container rp-group-mappings {
          list rp-group-mapping {
            key "id";
            leaf target-class-id id {
              type string; uint16;
              description
       "Identification of the class of service.
       This
                "Unique identifier is internal to the administration.";
      }
      description
      "List of marking rules.";
     }
     description
     "Configuration of for the traffic classification policy."; mapping.";
            }
            container qos-profile {
     choice qos-profile {
      description
      "Choice for QoS profile.
      Can be standard profile or customized profile.";
      case standard provider-managed {
       description
       "Standard QoS profile.";
              leaf profile enabled {
                type leafref {
        path "/l3vpn-ntw/vpn-profiles/valid-provider-identifiers"+
            "/qos-profile-identifier/id";
        } boolean;
                default "false";
                description
        "QoS profile
                  "Set to true if the Rendezvous Point (RP)
                   must be used."; a provider-managed node.  Set to false
                   if it is a customer-managed node.";
              }
              leaf direction rp-redundancy {
                type identityref {
           base qos-profile-direction;} boolean;
                default both; "false";
                description
             "The direction to which
                  "If true, a redundancy mechanism for the QoS profile RP
                   is applied.";
       } required.";
              }
      case custom
              leaf optimal-traffic-delivery {
                type boolean;
                default "false";
                description
       "Customized QoS profile.";
                  "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 classes anycast {
         if-feature qos-custom;
         list class
                when "../rp-redundancy = 'true' and
                      ../optimal-traffic-delivery = 'true'" {
          key class-id;
                    description
                      "Only applicable if
                       RP redundancy is
                       enabled and delivery through
                       optimal path is activated.";
                }
                leaf class-id local-address {
                  type string; inet:ip-address;
                  description
                   "Identification of the class of service.
                   This identifier is internal
                    "IP local address for PIM RP.
                     Usually, it corresponds to the
                   administration."; router
                     ID or primary address";
                }
          leaf direction
                leaf-list rp-set-address {
                  type identityref {
                    base qos-profile-direction;
                    }
                   default both; inet:ip-address;
                  description
                    "The direction to which
                    "Address other RP routers
                     that share the QoS profile
                    is applied."; same RP IP address.";
                }
                description
                  "PIM Anycast-RP parameters.";
              }
              description
                "Parameters for a provider-managed RP.";
            }
            leaf rate-limit rp-address {
                   type decimal64
              when "../provider-managed/enabled = 'false'" {
                    fraction-digits 5;
                    range "0..100";
                description
                  "Relevant when the RP is not provider-managed.";
              }
                   units percent;
              type inet:ip-address;
              mandatory true;
              description
                    "To be used if
                "Defines the class must be rate-limited.
                    Expressed as percentage address of the service
                    bandwidth."; RP.
                 Used if the RP is customer-managed.";
            }
            container latency {
          choice flavor groups {
           case lowest
              list group {
                key "id";
                leaf use-lowest-latency id {
                  type empty; uint16;
                  description
              "The traffic class should use the path with
                    "Identifier for the
              lowest latency."; group.";
                }
                uses multicast-rp-group-cfg;
                description
                  "List of multicast groups.";
              }
           case boundary {
            leaf jitter-boundary {
             type uint16;
             units msec;
             default 400;
              description
              "The traffic class should use a path
                "Multicast groups associated with a
              defined maximum latency.";
            } the RP.";
            }
            description
           "Latency constraint on the traffic class.";
              "List of RP-to-group mappings.";
          }
          description
          "Latency constraint on the traffic class.";
            "RP-to-group mappings parameters.";
        }
        container jitter {
          choice flavor {
           case lowest rp-discovery {
          leaf use-lowest-jitter rp-discovery-type {
            type empty;
              description
              "The traffic class should use the path with the
              lowest jitter."; identityref {
              base l3vpn-svc:multicast-rp-discovery-type;
            }
            default "l3vpn-svc:static-rp";
            description
              "Type of RP discovery used.";
          }
           case boundary
          container bsr-candidates {
            leaf latency-boundary
            when "derived-from-or-self(../rp-discovery-type, "
               + "'l3vpn-ntw:bsr-rp')" {
              description
                "Only applicable if discovery type uint32;
             units usec;
             default 40000;
                 is BSR-RP.";
            }
            leaf-list bsr-candidate-address {
              type inet:ip-address;
              description
              "The traffic class should use a path with a
              defined maximum jitter.";
                "Address of candidate Bootstrap Router (BSR).";
            }
            description
              "Container for List of Customer
               BSR candidate's addresses.";
          }
          description
           "Jitter constraint on the traffic class.";
            "RP discovery parameters.";
        }
        description
          "Jitter constraint on the traffic class.";
          "RP parameters.";
      }
      container bandwidth msdp {
        if-feature "msdp";
        leaf guaranteed-bw-percent enabled {
          type decimal64 {
                   fraction-digits 5;
                   range "0..100"; boolean;
          default "false";
          description
            "If true, Multicast Source Discovery Protocol (MSDP)
             protocol is activated.";
        }
           units percent;
           mandatory true;
        leaf peer {
          type inet:ip-address;
          description
            "To be used to define the guaranteed bandwidth
            as a percentage
            "IP address of the available service bandwidth."; MSDP peer.";
        }
        leaf end-to-end local-address {
          type empty; inet:ip-address;
          description
            "Used if
            "IP address of the bandwidth reservation local end. This local address
             must be done on the MPLS network too.";
          }
          description
          "Bandwidth constraint configured on the traffic class."; node.";
        }
        description
         "List of classes of services.";
          "MSDP parameters.";
      }
      description
        "Container
        "Multicast global parameters for list of classes of services.";
       }
      } the VPN service.";
    }
    description
     "QoS profile configuration.";
      "Grouping for multicast VPN definition.";
  }

  grouping vpn-service-mpls {
    leaf carrierscarrier {
      if-feature "l3vpn-svc:carrierscarrier";
      type boolean;
      default "false";
      description
    "QoS configuration.";
        "The VPN is using CsC, and so MPLS is required.";
    }
    description
   "This grouping defines QoS parameters
      "Grouping for a site."; MPLS Carriers'Carrier definition.";
  }

  grouping site-security-authentication operational-requirements {
   container authentication
    leaf requested-site-start {
      type yang:date-and-time;
      description
      "Authentication parameters.";
        "Optional leaf indicating requested date and
         time when the service at a particular site is
         expected to start.";
    }
    leaf requested-site-stop {
      type yang:date-and-time;
      description
        "Optional leaf indicating requested date and
         time when the service at a particular site is
         expected to stop.";
    }
    description
      "This grouping defines authentication parameters for a site."; some operational
       parameters.";
  }

  grouping site-security-encryption status-timestamp {
   container encryption {
     if-feature encryption;
    leaf enabled status {
       type boolean;
       default false;
       description
       "If true, traffic encryption on the connection is required.";
      type operational-type;
      description
        "Operations status";
    }
    leaf layer timestamp {
      type yang:date-and-time;
      description
        "Indicates the actual date and time when "../enabled = 'true'" {
         the service actually started (UP) or
         stopped (DOWN).";
    }
    description
         "Require a value
      "This grouping defines some operational
       parameters for layer when enabled is true."; the service.";
  }
       type enumeration

  grouping service-status {
         enum layer2
    container service-status {
      container admin {
        uses status-timestamp;
        description
         "Encryption will occur at Layer 2.";
          "Administrative service status.";
      }
         enum layer3
      container ops {
        config false;
        uses status-timestamp;
        description
         "Encryption will occur at Layer 3.
         For example, IPsec may be used when
         a customer requests Layer 3 encryption.";
        }
          "Operational service status.";
      }
      description
     "Layer on which encryption is applied.";
        "Service status.";
    }
    description
     "";
      "Service status grouping. Reused in
       vpn-node and vpn-network-access.";
  }
   container encryption-profile {
     choice profile {
       case provider-profile

  grouping site-service-basic {
    leaf profile-name svc-input-bandwidth {
      type leafref {
             path "/l3vpn-ntw/vpn-profiles/valid-provider-identifiers"+
               "/encryption-profile-identifier/id";
            } uint64;
      units "bps";
      mandatory true;
      description
            "Name
        "From the customer site's perspective, the service
         input bandwidth of the connection or download
         bandwidth from the SP profile to be applied.";
         } the site.";
    }
       case customer-profile {
    leaf algorithm svc-output-bandwidth {
      type string; uint64;
      units "bps";
      mandatory true;
      description
           "Encryption algorithm
        "From the customer site's perspective, the service
         output bandwidth of the connection or upload
         bandwidth from the site to be used.";
         }
       }
     description
     ""; the SP.";
    }
     choice key-type {
       default psk;
       case psk {
    leaf preshared-key svc-mtu {
      type string; uint16;
      units "bytes";
      mandatory true;
      description
           "Pre-Shared Key (PSK) coming from
        "MTU at service level.  If the customer.";
         }
       }
       description
       "Choice of encryption profile.
       The encryption profile can be service is IP,
         it refers to the provider profile
       or customer profile.";
     }
     description
     "This grouping defines encryption 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.";
  }
   description
   "";
  }

  grouping site-routing site-protection {
    container routing-protocols {
    list routing-protocol traffic-protection {
     key id;
     leaf id{
     type string;
     description
     "";
     }
      if-feature "l3vpn-svc:fast-reroute";
      leaf type enabled {
        type identityref {
       base routing-protocol-type;
      } boolean;
        default "false";
        description
      "Type
          "Enables traffic protection of routing protocol."; access link.";
      }

     list routing-profiles {
       key "id";

       leaf id {
        type leafref {
         path "/l3vpn-ntw/vpn-profiles/valid-provider-identifiers"+
              "/routing-profile-identifier/id";
      description
        "Fast Reroute service parameters for the site.";
    }
    description
        "Routing profile to be used.";
      "Defines protection service parameters for a site.";
  }

  grouping site-service-mpls {
    container carrierscarrier {
      if-feature "l3vpn-svc:carrierscarrier";
      leaf type signalling-type {
        type ie-type;
         description
         "Import, export or both.";
       }

    description
   "Import or Export profile reference";
     }
     container ospf enumeration {
      when "derived-from-or-self(../type, 'l3vpn-ntw:ospf')"
          enum ldp {
            description
      "Only applies when
              "Use LDP as the signalling protocol is OSPF.";
               between the PE and the CE.  In this case,
               an IGP routing protocol must also be activated.";
          }
      if-feature rtg-ospf;
      leaf-list address-family
          enum bgp {
       type address-family;
           min-elements "1";
            description
          "If OSPF is used on this site,
              "Use BGP as the signalling protocol
               between the PE and the CE.
               In this node
          contains a case, BGP must also be configured value.  This node
          contains at least one address family as
               the routing protocol.";
            reference
              "RFC 8277: Using BGP to be activated."; Bind MPLS Labels to
                         Address Prefixes";
          }
      leaf area-address {
       type yang:dotted-quad;
       mandatory true;
          description
          "Area address.";
        }
      leaf metric {
       type uint16;
        default 1; "bgp";
        description
          "Metric of
          "MPLS signalling type.";
      }
      description
        "This container is used when the PE-CE link.  It customer provides
         MPLS-based services.  This is only used in the routing state calculation and
          path selection.";
      }

      /* Extension */

      leaf mtu {
          type uint16; case
         of CsC (i.e., a customer builds an MPLS service using
         an IP VPN to carry its traffic).";
    }
    description "Maximum transmission unit
      "Defines MPLS service parameters for a given
          OSPF link."; site.";
  }

      leaf process-id

  grouping ports {
          type uint16;
    choice source-port {
      container source-port-range-or-operator {
        uses packet-fields:port-range-or-operator;
        description
          "Process id
          "Source port definition.";
      }
      description
        "Choice of specifying the OSPF CE-PE connection."; source port or referring to
         a group of source port numbers.";
    }
    choice destination-port {
      container destination-port-range-or-operator {
        uses security-params;

      /* End packet-fields:port-range-or-operator;
        description
          "Destination port definition.";
      }
      description
        "Choice of Extension */ specifying a destination port or referring
         to a group of destination port numbers.";
    }
    description
      "Choice of specifying a source or destination port numbers.";
  }

  grouping site-service-qos-profile {
    container sham-links qos {
      if-feature rtg-ospf-sham-link; "l3vpn-svc:qos";
      container qos-classification-policy {
        list sham-link rule {
          key target-site; "id";
          ordered-by user;
          leaf target-site id {
            type svc-id; string;
            description
          "Target site for
              "A description identifying the sham link connection.
          The site is referred to by its ID.";
               qos-classification-policy rule.";
          }
        leaf metric
          choice match-type {
         type uint16;
            default 1; "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
          "Metric of the sham link.  It is used in
          the routing state calculation and path
          selection.  The default value is
                    "Rule set
          to 1.";
        }
          description
          "Creates a sham link with another site."; that matches IPv4 header.";
                }
                container ipv6 {
                  uses packet-fields:acl-ip-header-fields;
                  uses packet-fields:acl-ipv6-header-fields;
                  description
       "List of sham links.";
                    "Rule set that matches IPv6 header.";
                }
                description
      "OSPF-specific configuration.";
                  "Either IPv4 or IPv6.";
              }
     container bgp
              choice l4 {
      when "derived-from-or-self(../type, 'l3vpn-ntw:bgp')"
                container tcp {
                  uses packet-fields:acl-tcp-header-fields;
                  uses ports;
                  description
       "Only applies when protocol is BGP.";
                    "Rule set that matches TCP header.";
                }
      if-feature rtg-bgp;
      leaf autonomous-system
                container udp {
       type uint32;
       mandatory true;
                  uses packet-fields:acl-udp-header-fields;
                  uses ports;
                  description
          "Customer AS number in case the customer
          requests BGP routing.";
                    "Rule set that matches UDP header.";
                }
      leaf-list address-family {
       type 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
                  "Can be activated."; TCP or UDP";
              }
      /*  Extension  */
            }
            case match-application {
              leaf neighbor match-application {
                type inet:ip-address; identityref {
                  base l3vpn-svc:customer-application;
                }
                description
          "IP address of
                  "Defines the BGP neighbor."; application to match.";
              }
            }
            description
              "Choice for classification.";
          }
          leaf multihop target-class-id {
            type uint8; string;
            description
          "Describes the number
              "Identification of hops allowed between the
          given BGP neighbor and class of service.
               This identifier is internal to the PE router."; administration.";
          }

      uses security-params;
          description
      "BGP-specific configuration.";
            "List of marking rules.";
        }
        description
          "Configuration of the traffic classification policy.";
      }
      container static qos-profile {
      when "derived-from-or-self(../type, 'l3vpn-ntw:static')"
        choice qos-profile {
          description
        "Only applies when protocol is static.
        BGP activation requires the SP to know
        the address of the customer peer.  When
        BGP is enabled, the 'static-address'
        allocation type
            "Choice for the IP connection
        MUST QoS profile.
             Can be standard profile or customized profile.";
          case standard {
            description
              "Standard QoS profile.";
            leaf profile {
              type leafref {
                path "/l3vpn-ntw/vpn-profiles/"
                   + "valid-provider-identifiers"
                   + "/qos-profile-identifier/id";
              }
              description
                "QoS profile to be used.";
            }
            leaf direction {
              type identityref {
                base l3vpn-svc:qos-profile-direction;
              }
              default "l3vpn-svc:both";
              description
                "The direction to which the QoS profile
                 is applied.";
            }
          }
          case custom {
            description
              "Customized QoS profile.";
            container cascaded-lan-prefixes classes {
              if-feature "l3vpn-svc:qos-custom";
              list ipv4-lan-prefixes class {
        if-feature ipv4;
                key "lan next-hop"; "class-id";
                leaf lan class-id {
                  type inet:ipv4-prefix; string;
                  description
         "LAN prefixes.";
                    "Identification of the class of service.
                     This identifier is internal to the
                     administration.";
                }
                leaf lan-tag direction {
                  type string; identityref {
                    base l3vpn-svc:qos-profile-direction;
                  }
                  default "l3vpn-svc:both";
                  description
          "Internal tag
                    "The direction to be used in VPN policies."; which the QoS profile
                     is applied.";
                }
                leaf next-hop rate-limit {
                  type inet:ipv4-address;
          description
          "Next-hop address to use on the customer side."; decimal64 {
                    fraction-digits 5;
                    range "0..100";
                  }
                  units "percent";
                  description
        "List
                    "To be used if the class must be rate-limited.
                     Expressed as percentage of LAN prefixes for the site."; service
                     bandwidth.";

                }
       list ipv6-lan-prefixes
                container latency {
                  choice flavor {
                    case lowest {
        if-feature ipv6;
        key "lan next-hop";
                      leaf lan use-lowest-latency {
                        type inet:ipv6-prefix; empty;
                        description
          "LAN prefixes.";
                          "The traffic class should
                           use the path with the
                           lowest latency.";
                      }
        leaf lan-tag {
         type string;
         description
         "Internal tag to be used in VPN policies.";
                    }
                    case boundary {
                      leaf next-hop jitter-boundary {
                        type inet:ipv6-address; uint16;
                        units "msec";
                        default "400";
                        description
          "Next-hop address to
                          "The traffic class
                           should use on the customer side."; a path with a
                           defined maximum latency.";
                      }
        description
        "List of LAN prefixes for the site.";
                    }
                    description
       "LAN prefixes from
                      "Latency constraint
                       on the customer."; traffic class.";
                  }
                  description
      "Configuration specific to static routing.";
                    "Latency constraint
                     on the traffic class.";
                }
                container rip jitter {
      when "derived-from-or-self(../type, 'l3vpn-ntw:rip')"
                  choice flavor {
                    case lowest {
                      leaf use-lowest-jitter {
                        type empty;
                        description
       "Only applies when
                          "The traffic class
                           should use the protocol is RIP.  For IPv4, path with the model assumes that RIP version 2 is used.";
                           lowest jitter.";
                      }
      if-feature rtg-rip;
      leaf-list address-family
                    }
                    case boundary {
                      leaf latency-boundary {
                        type address-family;
           min-elements "1"; uint32;
                        units "usec";
                        default "40000";
                        description
          "If RIP is used on this site, this node
          contains
                          "The traffic class
                           should use a configured value.  This node
          contains at least one address family
          to be activated."; path with a
                           defined maximum jitter.";
                      }
                    }
                    description
      "Configuration specific to RIP routing.";
                      "Jitter constraint on the traffic class.";
                  }
     container vrrp {
      when "derived-from-or-self(../type, 'l3vpn-ntw:vrrp')" {
                  description
       "Only applies when protocol is VRRP.";
                    "Jitter constraint on the traffic class.";
                }
      if-feature rtg-vrrp;
      leaf-list address-family
                container bandwidth {
                  leaf guaranteed-bw-percent {
                    type address-family;
           min-elements "1"; decimal64 {
                      fraction-digits 5;
                      range "0..100";
                    }
                    units "percent";
                    mandatory true;
                    description
          "If VRRP is
                      "To be used on this site, this node
          contains a configured value.  This node contains
          at least one address family to define the guaranteed bandwidth
                       as a percentage of the available service
                       bandwidth.";
                  }
                  leaf end-to-end {
                    type empty;
                    description
                      "Used if the bandwidth reservation
                       must be activated."; done on the MPLS network too.";
                  }
                  description
      "Configuration specific to VRRP routing.";
                    "Bandwidth constraint on the traffic class.";
                }
                description
                  "List of routing protocols used on
     the site.  This classes of services.";
              }
              description
                "Container for list can be augmented."; of classes of services.";
            }
          }
        }
        description
    "Defines routing protocols.";
          "QoS profile configuration.";
      }
      description
   "Grouping
        "QoS configuration.";
    }
    description
      "This grouping defines QoS parameters for routing protocols."; a site.";
  }

  grouping site-attachment-ip-connection site-security-authentication {
    container ip-connection authentication {
      description
        "Authentication parameters.";
    }
    description
      "This grouping defines authentication parameters
       for a site.";
  }

  grouping site-security-encryption {
    container ipv4 encryption {
      if-feature ipv4; "l3vpn-svc:encryption";
      leaf address-allocation-type enabled {
        type identityref {
        base address-allocation-type;
      }
      must "not(derived-from-or-self(current(), 'l3vpn-ntw:slaac') or "+
          "derived-from-or-self(current(), "+
          "'l3vpn-ntw:provider-dhcp-slaac'))" {
      error-message "SLAAC is only applicable to IPv6";
      } boolean;
        default "false";
        description
      "Defines how addresses are allocated.
      If there is no value for
          "If true, traffic encryption on the address
      allocation type, then IPv4 connection
           is not enabled."; required. It is disabled, otherwise.";
      }
    container provider-dhcp
      leaf layer {
        when "derived-from-or-self(../address-allocation-type, "+
      "'l3vpn-ntw:provider-dhcp')" "../enabled = 'true'" {
          description
      "Only applies
            "Require a value for layer 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 enabled
             is specified, then
          the prefix length may or may not be specified."; true.";
        }
      leaf prefix-length {
        type uint8 enumeration {
       range "0..32";
          enum layer2 {
            description
              "Encryption will occur at Layer 2.";
          }
          must "(../provider-address)"
          enum layer3 {
           error-message
           "If the prefix length is specified, provider-address
           must also
            description
              "Encryption will occur at Layer 3.
               For example, IPsec may be specified."; used when
               a customer requests Layer 3 encryption.";
          }
        }
        description
              "If the prefix length
          "Layer on which encryption is specified, provider-address
              must also be specified."; applied.";
      }
      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 encryption-profile {
      choice address-assign profile {
       default number;
        case number provider-profile {
          leaf number-of-dynamic-address profile-name {
            type uint16;
         default 1; leafref {
              path "/l3vpn-ntw/vpn-profiles/"
                 + "valid-provider-identifiers"
                 + "/encryption-profile-identifier/id";
            }
            description
          "Describes the number
              "Name of IP addresses the customer requires."; SP profile to be applied.";
          }
        }
        case explicit {
        container customer-addresses {
         list address-group customer-profile {
          key "group-id";
          leaf group-id algorithm {
            type string;
            description
          "Group-id for the address range from
          start-address
              "Encryption algorithm to end-address."; be used.";
          }
        }
         leaf start-address {
          type inet:ipv4-address;
        description
           "First address.";
          "";
      }
      choice key-type {
        default "psk";
        case psk {
          leaf end-address preshared-key {
            type inet:ipv4-address; string;
            description
          "Last address.";
              "Pre-Shared Key (PSK) coming from the customer.";
          }
          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
          "Choice of encryption profile.
           The encryption profile can be the provider profile
           or customer addresses is allocated by DHCP.";
        } profile.";
      }
      description
          "Choice
        "This grouping defines encryption parameters for the way to assign addresses.";
         a site.";
    }
    description
          "DHCP allocated addresses related parameters.";
      "";
  }
  container dhcp-relay

  grouping site-routing {
    when "derived-from-or-self(../address-allocation-type, "+
    "'l3vpn-ntw:provider-dhcp-relay')"
    container routing-protocols {
      description
      "Only applies when provider is required to implement
      DHCP relay function.";
   }
      list routing-protocol {
        key "id";
        leaf provider-address id {
          type inet:ipv4-address; string;
          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 { type uint8 {
   range "0..32";
   }
  must "(../provider-address)"
          type identityref {
   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.";
            base l3vpn-svc:routing-protocol-type;
          }
          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.";
            "Type of routing protocol.";
        }
  container customer-dhcp-servers
        list routing-profiles {
   leaf-list server-ip-address
          key "id";
          leaf id {
            type inet:ipv4-address; leafref {
              path "/l3vpn-ntw/vpn-profiles/"
                 + "valid-provider-identifiers"
                 + "/routing-profile-identifier/id";
            }
            description
      "IP address of customer DHCP server.";
              "Routing profile to be used.";
          }
          leaf type {
            type ie-type;
            description
  "Container for list of customer DHCP servers.";
              "Import, export or both.";
          }
          description
  "DHCP relay provided by operator.";
            "Import or Export profile reference";
        }
        container static-addresses ospf {
          when "derived-from-or-self(../address-allocation-type, "+
    "'l3vpn-ntw:static-address')" "derived-from-or-self(../type, 'l3vpn-ntw:ospf')" {
            description
              "Only applies when protocol allocation type is static."; OSPF.";
          }
     leaf primary-address{
     type leafref
          if-feature "l3vpn-svc:rtg-ospf";
          leaf-list address-family {
      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";
     }
            type l3vpn-svc:address-family;
            min-elements 1;
            description
     "Principal
              "If OSPF is used on this site, this node
               contains a configured value.  This node
               contains at least one address of the connection."; family
               to be activated.";
          }
     list address{
     key address-id;
          leaf address-id area-address {
            type string; yang:dotted-quad;
            mandatory true;
            description
      "IPv4 Address";
              "Area address.";
          }
          leaf provider-address metric {
            type inet:ipv4-address; uint16;
            default "1";
            description
          "IPv4 Address List
              "Metric of the provider side.
          When the protocol allocation type PE-CE link.  It is static, used
               in the provider address must be configured."; routing state calculation and
               path selection.";
          }
          /* Extension */
          leaf customer-address mtu {
            type inet:ipv4-address; uint16;
            description
          "IPv4 Address of customer side.";
              "Maximum transmission unit for a given
               OSPF link.";
          }
          leaf prefix-length process-id {
            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.";
     } uint16;
            description
     "IPv4-specific parameters.";
              "Process id of the OSPF CE-PE connection.";
          }
          uses security-params;
          /* End of Extension */
          container ipv6 sham-links {
            if-feature ipv6; "rtg-ospf-sham-link";
            list sham-link {
              key "target-site";
              leaf address-allocation-type target-site {
                type identityref {
       base address-allocation-type;
      } l3vpn-svc:svc-id;
                description
      "Defines how addresses are allocated.
      If there is no value
                  "Target site for the address
      allocation type, then IPv6 sham link connection.
                   The site is
      not enabled.";
     }

    container provider-dhcp {
       when "derived-from-or-self(../address-allocation-type, "+
       "'l3vpn-ntw:provider-dhcp') "+
       "or derived-from-or-self(../address-allocation-type, "+
       "'l3vpn-ntw:provider-dhcp-slaac')" {
       description
       "Only applies when addresses are allocated referred to by DHCP."; its ID.";
              }
              leaf provider-address metric {
                type inet:ipv6-address; uint16;
                default "1";
                description
            "Address
                  "Metric of the provider side.  If provider-address
            is not specified, then prefix length should not be
            specified either. sham link.  It also implies provider-dhcp
            allocation is not enabled.  If provider-address used in
                   the routing state calculation and path
                   selection.  The default value is
            specified, then prefix length may or may
            not be specified.";
          }
       leaf prefix-length {
        type uint8 {
        range "0..128"; set
                   to 1.";
              }
            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.";
                "Creates a sham link with another site.";
            }
            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.";
              "List of sham links.";
          }
         choice address-assign
          description
            "OSPF-specific configuration.";
        }
        container bgp {
          default number;
          case number
          when "derived-from-or-self(../type, 'l3vpn-ntw:bgp')" {
            description
              "Only applies when protocol is BGP.";
          }
          if-feature "l3vpn-svc:rtg-bgp";
          leaf number-of-dynamic-address peer-autonomous-system {
            type uint16;
            default 1; inet:as-number;
            mandatory true;
            description
            "Describes the
              "Customer AS number of IP addresses in case the customer
            requires.";

           }
               requests BGP routing.";
          }
          case explicit {
           container customer-addresses {
            list address-group {
                  key "group-id";
          leaf group-id local-autonomous-system {
            type string; inet:as-number;
            description
                  "Group-id for the
              "Local-AS overwrite.";
          }
          leaf-list address-family {
            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 range from
                  start-address family
               to end-address."; be activated.";
          }
                  leaf start-address
          /*  Extension  */
          leaf-list neighbor {
            type inet:ipv6-address; inet:ip-address;
            description
                   "First address.";
              "IP address(es) of the BGP neighbor. An IPv4
               and IPv6 neighbors may be indicated if
               two sessions will be used for IPv4 and IPv6.";
          }
          leaf end-address multihop {
            type inet:ipv6-address;
                   description
                   "Last address.";
                   } uint8;
            description
              "Describes IP addresses allocated by DHCP.  When only
                  start-address or only end-address is present, it
                  represents the number of hops allowed between
               a single address.  When both start-address given BGP neighbor and end-address are specified, it implies the PE router.";
          }
          uses security-params;
          uses status-params;
          leaf description {
            type string;
            description
              "Includes a range
                  inclusive description of both addresses.  If no address the BGP session.
               Such description is
                  specified, it implies customer addresses group meant to be used for
               diagnosis purposes. The semantic of the description
               is
                  not supported."; local to an implementation.";
          }
          /* End- Extension  */
          description
            "Container for customer addresses allocated by DHCP.";
            "BGP-specific configuration.";
        }
        container isis {
          when "derived-from-or-self(../type, 'l3vpn-ntw:isis')" {
            description
              "Only applies when protocol is ISIS.";
          }
          if-feature "rtg-isis";
          leaf-list address-family {
            type l3vpn-svc:address-family;
            min-elements 1;
            description
          "Choice for the way
              "If ISIS is used on this site, this node
               contains a configured value.  This node
               contains at least one address family
               to assign addresses."; be activated.";
          }
          leaf area-address {
            type area-address;
            mandatory true;
            description
          "DHCP allocated addresses related parameters.";
              "Area address.";
          }
    container dhcp-relay
          leaf level {
     when "derived-from-or-self(../address-allocation-type, "+
          "'l3vpn-ntw:provider-dhcp-relay')"
            type isis-level;
            description
              "level1, level2 or level1-2";
          }
          leaf metric {
            type uint16;
            default "1";
            description
       "Only applies when
              "Metric of the provider PE-CE link.  It is required
       to implement DHCP relay function."; used
               in the routing state calculation and
               path selection.";
          }
          leaf provider-address process-id {
            type inet:ipv6-address; uint16;
            description
           "Address
              "Process id 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."; ISIS CE-PE connection.";
          }
          leaf prefix-length mode {
            type uint8 enumeration {
           range "0..128";
           }
          must "(../provider-address)"
              enum active {
           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.";
                  "Interface sends or receives ISIS protocol
                   control packets.";
              }
              enum passive {
                description
          "Subnet prefix length expressed in bits.  If not
          specified, or specified as zero, this means the
          customer leaves
                  "Suppresses the actual prefix length value
          to sending of ISIS routing updates
                   through the provider."; specified interface.";
              }
            }
            default "active";
            description
              "ISIS interface mode type.";
          }
          uses status-params;
          description
            "ISIS-specific configuration.";
        }
        container customer-dhcp-servers static {
      leaf-list server-ip-address
          when "derived-from-or-self(../type, 'l3vpn-ntw:static')" {
       type inet:ipv6-address;
            description
        "This node contains the IP address of
        the customer DHCP server.  If the DHCP relay
        function
              "Only applies when protocol is implemented by static.
               BGP activation requires the
        provider, this node contains SP to know
               the
        configured value.";
      }
       description
       "Container for list address of the customer DHCP servers.";
      }
     description
     "DHCP relay provided by operator."; peer.  When
               BGP is enabled, the 'static-address'
               allocation type for the IP connection
               MUST be used.";
          }
          container static-addresses cascaded-lan-prefixes {
       when "derived-from-or-self(../address-allocation-type, "+
       "'l3vpn-ntw:static-address')"
            list ipv4-lan-prefixes {
              if-feature "l3vpn-svc:ipv4";
              key "lan next-hop";
              leaf lan {
       description
       "Only applies when protocol allocation
                type is static."; inet:ipv4-prefix;
                description
                  "LAN prefixes.";
              }
              leaf primary-address{
        type leafref lan-tag {
         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";
                type string;
                description
                  "Internal tag to be used in VPN policies.";

              }
              leaf next-hop {
                type inet:ipv4-address;
                description
        "Principal
                  "Next-hop address to use on the customer side.";
              }
              description
                "List of LAN prefixes for the connection"; site.";
            }
            list address{ ipv6-lan-prefixes {
              if-feature "l3vpn-svc:ipv6";
              key address-id; "lan next-hop";
              leaf address-id lan {
                type string; inet:ipv6-prefix;
                description
         "IPv4 Address";
                  "LAN prefixes.";
              }
              leaf provider-address lan-tag {
                type inet:ipv6-address; string;
                description
       "IPv6 Address of the provider side.  When the protocol
       allocation type is static, the provider address
       must
                  "Internal tag to be configured."; used in VPN policies.";
              }
              leaf customer-address next-hop {
                type inet:ipv6-address;
                description
       "The IPv6 Address of
                  "Next-hop address to use on 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.";
                "List of LAN prefixes for the site.";
            }
            description
     "IPv6-specific parameters.";
              "LAN prefixes from the customer.";
          }
          description
     "IPv6-specific parameters.";
            "Configuration specific to static routing.";
        }
        container oam {
     container bfd {
      if-feature bfd;
      leaf enabled {
       type boolean;
       default false;
       description
       "If true, BFD activation is required.";
      }
      choice holdtime {
       default fixed;
       case fixed rip {
        leaf fixed-value
          when "derived-from-or-self(../type, 'l3vpn-ntw:rip')" {
         type uint32;
         units msec;
            description
          "Expected BFD holdtime expressed in msec.  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
              "Only applies when the customer to use this
          function, protocol is RIP.  For IPv4,
               the fixed-value will not be set.";
        } model assumes that RIP version 2 is used.";
          }
       case profile {
        leaf profile-name
          if-feature "l3vpn-svc:rtg-rip";
          leaf-list address-family {
            type leafref {
          path "/l3vpn-ntw/vpn-profiles/valid-provider-identifiers/"+
                  "bfd-profile-identifier/id";
         } l3vpn-svc:address-family;
            min-elements 1;
            description
         "Well-known SP profile name.  The provider can propose
         some profiles to the customer, depending
              "If RIP is used on the service
         level the customer wants this site, this node
               contains a configured value.  This node
               contains at least one address family
               to achieve.  Profile names
         must be communicated activated.";
          }
          description
            "Configuration specific to the customer."; RIP routing.";
        }
        container vrrp {
          when "derived-from-or-self(../type, 'l3vpn-ntw:vrrp')" {
            description
        "Well-known SP profile.";
              "Only applies when protocol is VRRP.";
          }
          if-feature "l3vpn-svc:rtg-vrrp";
          leaf-list address-family {
            type l3vpn-svc:address-family;
            min-elements 1;
            description
       "Choice for holdtime flavor.";
              "If VRRP is used on this site, this node
               contains a configured value.  This node contains
               at least one address family to be activated.";
          }
          description
      "Container for BFD.";
            "Configuration specific to VRRP routing.";
        }
        description
     "Defines the Operations, Administration, and Maintenance (OAM)
     mechanisms
          "List of routing protocols used on
           the connection.  BFD is set as a fault
     detection mechanism, but the 'oam' container site.  This list can easily be augmented by other mechanisms"; augmented.";
      }
      description
        "Defines connection parameters."; routing protocols.";
    }
    description
   "This grouping defines IP connection parameters.";
      "Grouping for routing protocols.";
  }

  grouping site-service-multicast site-attachment-ip-connection {
    container multicast ip-connection {
      container ipv4 {
        if-feature multicast; "l3vpn-svc:ipv4";
        leaf multicast-site-type address-allocation-type {
          type enumeration {
      enum receiver-only identityref {
       description
       "The site only has receivers.";
            base l3vpn-svc:address-allocation-type;
          }
      enum source-only
          must "not(derived-from-or-self(current(), 'l3vpn-ntw:slaac')"
             + " or derived-from-or-self(current(), "
             + "'l3vpn-ntw:provider-dhcp-slaac'))" {
       description
       "The site
            error-message "SLAAC is only has sources.";
      }
      enum source-receiver {
       description
       "The site has both sources and receivers.";
      } applicable to IPv6";
          }
     default source-receiver;
          description
     "Type of multicast site.";
            "Defines how addresses are allocated.
             If there is no value for the address
             allocation type, then IPv4 is not enabled.";
        }
        container multicast-address-family provider-dhcp {
     leaf ipv4
          when "derived-from-or-self(../address-allocation-type, "
             + "'l3vpn-ntw:provider-dhcp')" {
      if-feature ipv4;
      type boolean;
      default false;
            description
      "Enables IPv4 multicast.";
              "Only applies when addresses are allocated by DHCP.";
          }
          leaf ipv6 provider-address {
      if-feature ipv6;
            type boolean;
      default false;
      description
      "Enables IPv6 multicast.";
     } inet:ipv4-address;
            description
     "Defines protocol to carry multicast.";
              "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 protocol-type prefix-length {
            type enumeration {
      enum host uint8 {
       description
       "Hosts are directly connected to the provider network.
       Host protocols such as IGMP or MLD are required.";
              range "0..32";
            }
      enum router
            must '(../provider-address)' {
       description
       "Hosts are behind a customer router.
       PIM will
              error-message
                "If the prefix length is specified, provider-address
                 must also be implemented.";
      }
      enum both { specified.";
              description
       "Some hosts are behind a customer router, and
       some others are directly connected to
                "If the
       provider network.  Both host and routing protocols prefix length is specified, provider-address
                 must also be used.  Typically, IGMP and PIM will be
       implemented.";
      } specified.";
            }
     default "both";
            description
     "Multicast protocol type to be used with
              "Subnet prefix length expressed in bits.
               If not specified, or specified as zero,
               this means the customer site.";
    }
    description
    "Multicast parameters for leaves the site."; actual
               prefix length value to the provider.";
          }
          choice address-assign {
            default "number";
            case number {
              leaf number-of-dynamic-address {
                type uint16;
                default "1";
                description
   "Multicast parameters for
                  "Describes the site."; number of IP addresses
                   the customer requires.";
              }

            }
  grouping site-maximum-routes
            case explicit {
              container maximum-routes customer-addresses {
                list address-family address-group {
                  key af; "group-id";
                  leaf af group-id {
                    type address-family; string;
                    description
      "Address family.";
                      "Group-id for the address range from
                       start-address to end-address.";
                  }
                  leaf maximum-routes start-address {
                    type uint32; inet:ipv4-address;
                    description
      "Maximum prefixes the VRF can accept
      for this address family.";
                      "First address.";
                  }
                  leaf end-address {
                    type inet:ipv4-address;
                    description
     "List of address families.";
                      "Last address.";
                  }
                  description
    "Defines 'maximum-routes' for the VRF.";
                    "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
   "Defines 'maximum-routes'
                  "Container for the site."; customer addresses is allocated by
                   DHCP.";
              }
  grouping site-security {
   container security {
    uses site-security-authentication;
    uses site-security-encryption;
    description
    "Site-specific security parameters.";
            }
            description
   "Grouping
              "Choice for security parameters.";
  }
  grouping network-access-service {
   container service {
    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 on the attachment."; way to assign addresses.";
          }
          description
   "Grouping for service
            "DHCP allocated addresses related parameters.";
        }
  grouping vpn-extranet {
        container extranet-vpns dhcp-relay {
    if-feature extranet-vpn;
    list extranet-vpn
          when "derived-from-or-self(../address-allocation-type, "
             + "'l3vpn-ntw:provider-dhcp-relay')" {
     key vpn-id;
            description
              "Only applies when provider is required to implement
               DHCP relay function.";
          }
          leaf vpn-id provider-address {
            type svc-id; inet:ipv4-address;
            description
      "Identifies the target VPN the local VPN want to access.";
              "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 local-sites-role prefix-length {
            type identityref uint8 {
       base site-role;
              range "0..32";
            }
      default any-to-any-role;
            must '(../provider-address)' {
              error-message
                "If prefix length is specified, provider-address
                 must also be specified.";
              description
      "This describes the role of the
      local sites in the target VPN topology.  In the any-to-any VPN
      service topology, the local sites
                "If prefix length is specified, provider-address
                 must have the same role, which
      will also be 'any-to-any-role'.  In the Hub-and-Spoke VPN service
      topology specified.";
            }
            description
              "Subnet prefix length expressed in bits.  If not
               specified, or specified as zero, this means the Hub-and-Spoke disjoint VPN service topology,
               customer leaves the local sites must have a Hub role or a Spoke role."; actual prefix length value
               to the provider.";
          }
          container customer-dhcp-servers {
            leaf-list server-ip-address {
              type inet:ipv4-address;
              description
     "List
                "IP address of extranet VPNs or target VPNs the local VPN is
     attached to."; customer DHCP server.";
            }
            description
              "Container for extranet VPN configuration."; list of customer DHCP servers.";
          }
          description
   "Grouping for extranet VPN configuration.
   This provides an easy way to interconnect
   all sites from two VPNs.";
            "DHCP relay provided by operator.";
        }
  grouping vpn-profile-cfg {
        container valid-provider-identifiers static-addresses {
    list cloud-identifier
          when "derived-from-or-self(../address-allocation-type, "
             + "'l3vpn-ntw:static-address')" {
     if-feature cloud-access;
     key id;
            description
              "Only applies when protocol allocation type is static.";
          }
          leaf id primary-address {
            type string;
      description
      "Identification of cloud service.
      Local administration meaning."; 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";
            }
            description
     "List for Cloud Identifiers.";
              "Principal address of the connection.";
          }
          list encryption-profile-identifier address {
            key id; "address-id";
            leaf id address-id {
              type string;
              description
      "Identification
                "IPv4 Address";
            }
            leaf provider-address {
              type inet:ipv4-address;
              description
                "IPv4 Address List of the SP encryption profile
      to provider side.
                 When the protocol allocation type is static,
                 the provider address must be used.  Local administration meaning."; configured.";
            }
            leaf customer-address {
              type inet:ipv4-address;
              description
     "List for encryption profile identifiers.";
                "IPv4 Address of customer side.";
            }
    list qos-profile-identifier {
     key id;
            leaf id prefix-length {
              type string; uint8 {
                range "0..32";
              }
              description
      "Identification of the QoS Profile
                "Subnet prefix length expressed in bits.
                 It is applied to be used.
      Local administration meaning."; both provider-address
                 and customer-address.";
            }
            description
     "List for QoS Profile Identifiers.";
              "Describes IPv4 addresses used.";
          }
    list bfd-profile-identifier
          description
            "Describes IPv4 addresses used.";
        }
        description
          "IPv4-specific parameters.";
      }
      container ipv6 {
     key id;
        if-feature "l3vpn-svc:ipv6";
        leaf id address-allocation-type {
          type string;
      description
      "Identification of the SP BFD Profile to be used.
      Local administration meaning."; identityref {
            base l3vpn-svc:address-allocation-type;
          }
          description
     "List
            "Defines how addresses are allocated.
             If there is no value for BFD Profile identifiers."; the address
             allocation type, then IPv6 is
             not enabled.";
        }

    list routing-profile-identifier
        container provider-dhcp {
     key id;
          when "derived-from-or-self(../address-allocation-type, "
             + "'l3vpn-ntw:provider-dhcp') "
             + "or derived-from-or-self(../address-allocation-type, "
             + "'l3vpn-ntw:provider-dhcp-slaac')" {
            description
              "Only applies when addresses are allocated by DHCP.";
          }
          leaf id provider-address {
            type string; inet:ipv6-address;
            description
      "Identification
              "Address of the routing Profile to provider side.  If provider-address
               is not specified, then prefix length should not be used
      by the routing-protocols within sites and vpn-
      network-accesses. Local administration meaning.";
               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.";
          }
     description
     "List for Routing Profile Identifiers.";
          leaf prefix-length {
            type uint8 {
              range "0..128";
            }

      nacm:default-deny-write;
            must '(../provider-address)' {
              error-message
                "If prefix length is specified, provider-address
                 must also be specified.";
              description
      "Container for Valid Provider Identifies.";
                "If prefix length is specified, provider-address
                 must also be specified.";
            }
            description
    "Grouping for VPN Profile configuration.";
              "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.";
          }
  grouping vpn-svc-cfg
          choice address-assign {
            default "number";
            case number {
              leaf vpn-id number-of-dynamic-address {
                type svc-id; uint16;
                default "1";
                description
    "VPN identifier.  Local administration meaning.";
                  "Describes the number of IP addresses the customer
                   requires.";
              }
            }
            case explicit {
              container customer-addresses {
                list address-group {
                  key "group-id";
                  leaf customer-name group-id {
                    type string;
                    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 the VPN service to their end user
    on behalf of the original service provider (e.g., Tier-1
    provider), the original service provider may require the
    customer name to provide smooth activation/commissioning
    and operation
                      "Group-id for the service."; address range from
                       start-address to end-address.";
                  }
                  leaf vpn-service-topology start-address {
                    type identityref {
     base vpn-topology;
    }
    default any-to-any; inet:ipv6-address;
                    description
    "VPN service topology.";
                      "First address.";
                  }
                  leaf description end-address {
                    type string; inet:ipv6-address;
                    description
       "Textual
                      "Last address.";
                  }
                  description of
                    "Describes IP addresses allocated by DHCP.
                     When only start-address or only end-address
                     is present, it represents a VPN service."; single address.
                     When both start-addressand 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.";
                }

   uses ie-profiles-params;
   uses vpn-nodes-params;
   uses vpn-service-multicast;
   /* uses vpn-service-mpls; */
   /* uses vpn-extranet;*/
                description
   "Grouping
                  "Container for VPN service configuration."; customer addresses allocated
                   by DHCP.";
              }
  grouping site-network-access-top-level-cfg {
   uses status-params;
   leaf vpn-network-access-type {
    type identityref {
     base site-network-access-type;
            }
    default point-to-point;
            description
    "Describes
              "Choice for the type of connection, e.g.,
    point-to-point or multipoint."; way to assign addresses.";
          }
   uses ethernet-params;
   uses site-attachment-ip-connection;
   uses site-security;
   uses site-routing;
          description
   "Grouping for site network access top-level configuration.";
  }

   /* Bearers in a site */
    grouping site-bearer-params {
            "DHCP allocated addresses related parameters.";

        }
        container site-bearers {
       list bearer dhcp-relay {
         key "bearer-id";
         leaf bearer-id
          when "derived-from-or-self(../address-allocation-type, "
             + "'l3vpn-ntw:provider-dhcp-relay')" {
           type string;
            description "";
              "Only applies when the provider is required
               to implement DHCP relay function.";
          }
          leaf BearerType provider-address {
            type identityref {
           base bearer-inf-type;
         } inet:ipv6-address;
            description
           "Request for an Bearer access type.
           Choose between port
              "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 lag connection type."; may
               not be specified.";
          }
          leaf ne-id prefix-length {
            type string;
         description
           "NE-id reference.";
         }

         leaf port-id uint8 {
           type string;
           description
           "Port-id in format slot/ card /port.";
              range "0..128";
            }
         leaf lag-id
            must '(../provider-address)' {
           type string;
           description
           "lag-id in format id.";
         }
              error-message
                "If prefix length is specified, provider-address
                 must also be specified.";
              description
     "Parameters used to identify each bearer";
                "If prefix length is specified, provider-address
                 must also be specified.";
            }
            description
     "Grouping to reuse
              "Subnet prefix length expressed in bits.  If not
               specified, or specified as zero, this means the site bearer assigment";
     }
     description
     "Grouping
               customer leaves the actual prefix length value
               to reuse the site bearer assigment"; provider.";
          }

    /* UNUSED */
    grouping svc-bandwidth-params {
          container svc-bandwidth {
         if-feature "input-bw";
         list bandwidth customer-dhcp-servers {
           key "direction type";
           leaf direction
            leaf-list server-ip-address {
              type identityref {
               base bw-direction;
             } inet:ipv6-address;
              description
               "Indicates the bandwidth direction.  It can be
                the bandwidth download direction from the SP to
                "This node contains the site or IP address of
                 the bandwidth upload direction from customer DHCP server.  If the site to DHCP relay
                 function is implemented by the SP.";
           }
           leaf type {
             type identityref {
               base bw-type;
                 provider, this node contains the
                 configured value.";
            }
            description
               "Bandwidth type.  By default, the bandwidth type
                is set to 'bw-per-cos'.";
              "Container for list of customer DHCP servers.";

          }
           leaf cos-id
          description
            "DHCP relay provided by operator.";
        }
        container static-addresses {
          when "derived-from-or-self(../type, "derived-from-or-self(../address-allocation-type, "
             + "'l3vpn-ntw:bw-per-cos')" "'l3vpn-ntw:static-address')" {
            description
                 "Relevant
              "Only applies when the bandwidth protocol allocation type is set to
                  'bw-per-cos'."; static.";
          }
          leaf primary-address {
            type uint8; 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";
            }
            description
               "Identifier
              "Principal address of the CoS, indicated by DSCP or a
                CE-VLAN CoS (802.1p) value in the service frame.
                If the bandwidth type is set to 'bw-per-cos',
                the CoS ID MUST also be specified."; connection";
          }
           leaf vpn-id
          list address {
             when "derived-from-or-self(../type, "
                + "'l3vpn-ntw:bw-per-svc')"
            key "address-id";
            leaf address-id {
               description
                 "Relevant when the bandwidth
              type is
                  set as bandwidth per VPN service."; string;
              description
                "IPv4 Address";
            }
            leaf provider-address {
              type svc-id; inet:ipv6-address;
              description
               "Identifies
                "IPv6 Address of the target VPN.  If provider side.  When the bandwidth protocol
                 allocation type is set as bandwidth per VPN service, static, the
                vpn-id MUST provider address
                 must be specified."; configured.";
            }
            leaf cir customer-address {
              type uint64;
             units "bps";
             mandatory true; inet:ipv6-address;
              description
               "Committed Information Rate.  The maximum number
                "The IPv6 Address of bits that a port can receive or send over
                an interface in one second."; the customer side.";
            }
            leaf cbs prefix-length {
              type uint64;
             units "bps";
             mandatory true; uint8 {
                range "0..128";
              }
              description
               "Committed Burst Size (CBS).  Controls the bursty
                nature of the traffic.  Traffic that does not
                use the configured Committed Information Rate
                (CIR) accumulates credits until the credits
                reach the configured CBS.";
                "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-specific parameters.";
      }
      container oam {
        container bfd {
          if-feature "l3vpn-svc:bfd";
          leaf eir enabled {
            type uint64;
             units "bps"; boolean;
            default "false";
            description
               "Excess Information Rate (EIR), i.e., excess frame
                delivery allowed that
              "If true, BFD activation is not subject to an SLA.
                The traffic rate can be limited by the EIR."; required.";
          }
          choice holdtime {
            default "fixed";
            case fixed {
              leaf ebs fixed-value {
                type uint64; uint32;
                units "bps"; "msec";
                description
               "Excess Burst Size (EBS).
                  "Expected BFD holdtime expressed in msec.  The bandwidth available customer
                   may impose some fixed values for burst traffic from the EBS is subject to holdtime period
                   if the
                amount of bandwidth that is accumulated during
                periods when traffic allocated by provider allows the EIR
                policy is customer use this function.
                   If the provider doesn't allow the customer to use this
                   function, the fixed-value will not used."; be set.";
              }
            }
            case profile {
              leaf pir profile-name {
                type uint64;
             units "bps"; leafref {
                  path "/l3vpn-ntw/vpn-profiles/valid-provider-identifiers/"
                     + "bfd-profile-identifier/id";
                }
                description
               "Peak Information Rate, i.e., maximum frame
                delivery allowed.  It is equal
                  "Well-known SP profile name.  The provider can propose
                   some profiles to or less
                than the sum of customer, depending on the CIR and service
                   level the EIR."; customer wants to achieve.  Profile names
                   must be communicated to the customer.";
              }
           leaf pbs {
             type uint64;
             units "bps";
              description
               "Peak Burst Size.  It is measured in bytes per
                second.";
                "Well-known SP profile.";
            }
            description
             "List of bandwidth values (e.g., per CoS,
              per vpn-id).";
              "Choice for holdtime flavor.";
          }
          description
           "From the customer site's perspective, the service
            input/output bandwidth of
            "Container for BFD.";
        }
        description
          "Defines the connection or
            download/upload bandwidth from Operations, Administration, and Maintenance (OAM)
           mechanisms used on the SP/site
            to connection.  BFD is set as a fault
           detection mechanism, but the site/SP."; 'oam' container can easily
           be augmented by other mechanisms";
      }
      description
           " ";
        "Defines connection parameters.";
    }
    description
      "This grouping status-params defines IP connection parameters.";
  }

  grouping site-service-multicast {
    container status multicast {
      if-feature "l3vpn-svc:multicast";
      leaf admin-enabled site-type {
        type boolean; enumeration {
          enum receiver-only {
            description
         "Administrative Status UP/DOWN";
              "The site only has receivers.";
          }
       leaf oper-status
          enum source-only {
         type operational-type;
         config false;
            description
         "Operations status";
              "The site only has sources.";
          }
          enum source-receiver {
            description "";
              "The site has both sources and receivers.";
          }
        }
        default "source-receiver";
        description
     "Grouping used to join operational and administrative status
     is re used in the Site Network Acess and in the VPN-Node";
          "Type of multicast site.";
      }

   /* Parameters related to vpn-nodes (VRF config.) */
    grouping vpn-nodes-params {
      container vpn-nodes {
       description "";
       list vpn-node address-family {
         key "vpn-node-id ne-id";
        leaf vpn-node-id ipv4 {
          if-feature "l3vpn-svc:ipv4";
          type string; boolean;
          default "false";
          description "";
            "Enables IPv4 multicast.";
        }
        leaf autonomous-system ipv6 {
          if-feature "l3vpn-svc:ipv6";
          type uint32; boolean;
          default "false";
          description
             "Provider AS number in case the customer
             requests BGP routing.";
            "Enables IPv6 multicast.";
        }

         leaf description {
           type string;
           description
             "Textual
        description of a VPN node.";
          "Defines protocol to carry multicast.";
      }
      leaf ne-id protocol-type {
        type string; enumeration {
          enum host {
            description "";
              "Hosts are directly connected to the provider network.
               Host protocols such as IGMP or MLD are required.";
          }

         leaf router-id
          enum router {
           type inet:ip-address;
            description
           "router-id information can
              "Hosts are behind a customer router.
               PIM will be ipv4/6 addresses"; implemented.";
          }

         leaf address-family
          enum both {
          type address-family;
            description
          "Address family used for router-id information.";
              "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.";
          }

         leaf node-role {
           type identityref {
             base site-role;
        }
        default any-to-any-role; "both";
        description
           "Role of the vpn-node in
          "Multicast protocol type to be used with the IP VPN."; customer site.";
      }
         uses rt-rd;
         uses status-params;
         uses net-acc;
         uses site-maximum-routes;
      leaf node-ie-profile remote-source {
        type leafref {
             path "/l3vpn-ntw/vpn-services/"+
                  "vpn-service/ie-profiles/ie-profile/ie-profile-id";
           } boolean;
        default "false";
        description "";
          "When true, there is no PIM adjacency on the interface.";
      }
      description "";
       }
        "Multicast parameters for the site.";
    }
    description "Grouping to define VRF-specific configuration.";
      "Multicast parameters for the site.";
  }

   /* Parameters related to import and export profiles (RTs RDs.) */
  grouping ie-profiles-params site-maximum-routes {
    container ie-profiles maximum-routes {
      list ie-profile address-family {
        key "ie-profile-id"; "af";
        leaf ie-profile-id af {
          type string; l3vpn-svc:address-family;
          description
            "";
            "Address family.";
        }
         uses rt-rd;
        leaf maximum-routes {
          type uint32;
          description
     "";
            "Maximum prefixes the VRF can accept
             for this address family.";
        }
        description
     "";
          "List of address families.";
      }
      description
     "Grouping to specify rules
        "Defines 'maximum-routes' for route import and export"; the VRF.";
    }
    description
      "Defines 'maximum-routes' for the site.";
  }

  grouping pseudowire-params site-security {
    container pseudowire {
       /*leaf far-end {*/
       /*  description "IP of the remote peer of the pseudowire.";*/
       /*  type inet:ip-address;*/
       /*}*/
       leaf vcid security {
         type uint32;
         description
         "PW or VC identifier.";
       }
      uses site-security-authentication;
      uses site-security-encryption;
      description
     "Pseudowire termination parameters";
        "Site-specific security parameters.";
    }
    description
      "Grouping pseudowire termination parameters"; for security parameters.";
  }

  grouping security-params network-access-service {
    container security {
     leaf auth-key service {
         type string;
      uses site-service-basic;
      /* Extension */
      /* uses svc-bandwidth-params; */
      /* EoExt */
      uses site-service-qos-profile;
      uses site-service-mpls;
      uses site-service-multicast;
      description
           "MD5 authentication password for the connection towards
        "Service parameters on the
           customer edge.";
       }
     description
         "Container for aggregating any security parameter for routing
         sessions between a PE and a CE."; attachment.";
    }
    description
      "Grouping to define security parameters"; for service parameters.";
  }

  grouping ethernet-params vpn-extranet {
    container connection {
     leaf encapsulation-type extranet-vpns {
       type identityref
      if-feature "l3vpn-svc:extranet-vpn";
      list extranet-vpn {
         base encapsulation-type;
       }
       default "untagged-int";
        key "vpn-id";
        leaf vpn-id {
          type l3vpn-svc:svc-id;
          description
         "Encapsulation type.  By default,
            "Identifies the
          encapsulation type is set target VPN the local VPN want to 'untagged'."; access.";
        }
     container tagged-interface {
        leaf type local-sites-role {
          type identityref {
            base tagged-inf-type; l3vpn-svc:site-role;
          }
          default "priority-tagged"; "l3vpn-svc:any-to-any-role";
          description
           "Tagged interface type.  By default,
            "This describes the type role of the tagged interface is
            'priority-tagged'.";
       }
       container dot1q-vlan-tagged {
         when "derived-from-or-self(../type, "
            + "'l3vpn-ntw:dot1q')" {
           description
             "Only applies when
             local sites in the type of target VPN topology.  In the tagged
              interface is 'dot1q'.";
         }
         if-feature "dot1q";
         leaf tag-type {
           type identityref {
             base tag-type; 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 a Spoke role.";
        }
           default "c-vlan";
        description
             "Tag type.  By default,
          "List of extranet VPNs or target VPNs the tag type local VPN is
              'c-vlan'.";
           attached to.";
      }
         leaf cvlan-id {
           type uint16;
      description
             "VLAN identifier.";
        "Container for extranet VPN configuration.";
    }
    description
           "Tagged interface.";
      "Grouping for extranet VPN configuration.
       This provides an easy way to interconnect
       all sites from two VPNs.";
  }

  grouping vpn-profile-cfg {
    container priority-tagged valid-provider-identifiers {
         when "derived-from-or-self(../type, "
            + "'l3vpn-ntw:priority-tagged')"
      list cloud-identifier {
           description
             "Only applies when the type of the tagged
              interface is 'priority-tagged'.";
         }
        if-feature "l3vpn-svc:cloud-access";
        key "id";
        leaf tag-type id {
          type identityref {
             base tag-type;
           }
           default "c-vlan"; string;
          description
             "Tag type.  By default, the tag type is
              'c-vlan'.";
            "Identification of cloud service.
             Local administration meaning.";
        }
        description
           "Priority tagged.";
          "List for Cloud Identifiers.";
      }
       container qinq {
         when "derived-from-or-self(../type, "
            + "'l3vpn-ntw:qinq')"
      list encryption-profile-identifier {
           description
             "Only applies when the type of the tagged
              interface is 'qinq'.";
         }
         if-feature "qinq";
        key "id";
        leaf tag-type id {
          type identityref {
             base tag-type;
           }
           default "c-s-vlan"; string;
          description
             "Tag type.  By default,
            "Identification of the tag type is
              'c-s-vlan'."; SP encryption profile
             to be used.  Local administration meaning.";
        }
         leaf svlan-id {
           type uint16;
           mandatory true;
        description
             "SVLAN identifier.";
          "List for encryption profile identifiers.";
      }
      list qos-profile-identifier {
        key "id";
        leaf cvlan-id id {
          type uint16;
           mandatory true; string;
          description
             "CVLAN identifier.";
            "Identification of the QoS Profile to be used.
             Local administration meaning.";
        }
        description
           "QinQ.";
          "List for QoS Profile Identifiers.";
      }
       container qinany
      list bfd-profile-identifier {
         when "derived-from-or-self(../type, "
            + "'l3vpn-ntw:qinany')"
        key "id";
        leaf id {
           description
             "Only applies when the
          type string;
          description
            "Identification of the tagged
              interface is 'qinany'."; SP BFD Profile to be used.
             Local administration meaning.";
        }
         if-feature "qinany";
        description
          "List for BFD Profile identifiers.";
      }
      list routing-profile-identifier {
        key "id";
        leaf tag-type id {
          type identityref {
             base tag-type;
           }
           default "s-vlan"; string;
          description
             "Tag type.  By default,
            "Identification of the tag type is
              's-vlan'."; routing Profile 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.";
        }
         leaf svlan-id {
           type uint16;
           mandatory true;
        description
             "Service VLAN ID.";
          "List for Routing Profile Identifiers.";
      }
      nacm:default-deny-write;
      description
        "Container for QinAny."; Valid Provider Identifies.";
    }
       container vxlan
    description
      "Grouping for VPN Profile configuration.";
  }

  grouping vpn-svc-cfg {
         when "derived-from-or-self(../type, "
            + "'l3vpn-ntw:vxlan')"
    leaf vpn-id {
      type l3vpn-svc:svc-id;
      description
             "Only applies when
        "VPN identifier.
         This identifier has a local meaning.";
    }
    leaf l3sm-vpn-id {
      type l3vpn-svc:svc-id;
      description
        "Pointer to the L3SM service.";
    }
    leaf customer-name {
      type string;
      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 the VPN service to their end user
         on behalf of the tagged
              interface is 'vxlan'.";
         }
         if-feature "vxlan";
         leaf vni-id {
           type uint32;
           mandatory true;
           description
             "VXLAN Network Identifier (VNI)."; original service provider (e.g., Tier-1
         provider), the original service provider may require the
         customer name to provide smooth activation/commissioning
         and operation for the service.";
    }
    leaf peer-mode vpn-service-topology {
      type identityref {
        base vxlan-peer-mode; vpn-topology;
      }
      default "static-mode"; "any-to-any";
      description
             "Specifies the VXLAN access mode.  By default,
              the peer mode is set to 'static-mode'.";
        "VPN service topology.";
    }
         list peer-list {
           key "peer-ip";
    leaf peer-ip description {
      type inet:ip-address; string;
      description
               "Peer IP.";
           }
        "Textual description
             "List of peer IP addresses.";
         }
         description
           "QinQ."; a VPN service.";

    }
    uses ie-profiles-params;
    uses svc-transport-encapsulation;
    uses vpn-nodes-params;
    /* uses vpn-service-multicast; */
    /* uses vpn-service-mpls; */
    /* uses vpn-extranet;*/
    description
         "Container
      "Grouping for tagged interfaces."; VPN service configuration.";
  }
     container bearer

  grouping site-network-access-top-level-cfg {
    uses status-params;
    leaf bearer-reference vpn-network-access-type {
       if-feature bearer-reference;
      type string;
        description
        "This is an internal reference for the SP.";
      }
        uses pseudowire-params {
          when "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/"+
          "vpn-node/vpn-network-accesses/vpn-network-access/"+
          "vpn-network-access-type ='pseudowire'" identityref {
           description "pseudowire specific parameters";
           }
        base l3vpn-svc:site-network-access-type;
      }
      default "l3vpn-svc:point-to-point";
      description
     "Defines physical properties
        "Describes the type of a site attachment.";
     }
     description
     "Encapsulation types"; connection, e.g.,
         point-to-point or multipoint.";
    }
    uses ethernet-params;
    uses site-attachment-ip-connection;
    uses site-security;
    uses site-routing;
    uses network-access-service;
    description
      "Grouping to define encapsulation types"; for site network access top-level configuration.";
  }

  /* Bearers in a site */

  grouping rt-rd site-bearer-params {
    container site-bearers {
      list bearer {
        key "bearer-id";
        leaf rd bearer-id {
          type rt-types:route-distinguisher; string;
          description
            "";
        }
     container vpn-targets
        leaf BearerType {
          type identityref {
            base bearer-inf-type;
          }
          description
     "Set of route-targets to match
            "Request for import and export routes
      to/from VRF";
      uses rt-types:vpn-route-targets; an Bearer access type.

             Choose between port or lag connection type.";
        }
        leaf ne-id {
          type string;
          description
   "";
            "NE-id reference.";
        }

 grouping net-acc{
 container vpn-network-accesses {
      list vpn-network-access {
       key vpn-network-access-id;
        leaf vpn-network-access-id port-id {
          type svc-id; string;
          description
        "Identifier for
            "Reference to the Port-id.
             The semantic of the access."; 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";
        }
        leaf description lag-id {
          type string;
          description
           "Textual description of a VPN service.";
            "lag-id in format id.";
        }
       uses site-network-access-top-level-cfg;
        description
       "List of accesses for a site.";
          "Parameters used to identify each bearer";
      }
      description
      "List of accesses for a site.";
        "Grouping to reuse the site bearer assigment";
    }
    description
      "Main block of
      "Grouping to reuse the Network Access."; site bearer assigment";
  }

  /* Main blocks UNUSED */
  container l3vpn-ntw {
   container vpn-profiles

  grouping svc-bandwidth-params {
    uses vpn-profile-cfg;
     description
     "Container for VPN Profiles.";
   }
    container vpn-services svc-bandwidth {
      if-feature "input-bw";
      list vpn-service bandwidth {
        key vpn-id;
     uses vpn-svc-cfg;
     description
     "List of VPN services."; "direction type";
        leaf direction {
          type identityref {
            base bw-direction;
          }
          description
    "Top-level container for
            "Indicates the VPN services.";
   }
   description
   "Main container for L3VPN service configuration.";
  }
 }
 <CODE ENDS>

                                 Figure 15

8.  IANA Considerations

   This document requests IANA to register bandwidth direction.  It can be
             the following URI in bandwidth download direction from the "ns"
   subregistry within SP to
             the "IETF XML Registry" [RFC3688]:

      URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw

      Registrant Contact: The IESG.

      XML: N/A; site or the requested URI is an XML namespace.

   This document requests IANA bandwidth upload direction from
             the site to register the following YANG module in SP.";
        }
        leaf type {
          type identityref {
            base bw-type;
          }
          description
            "Bandwidth type.  By default, the "YANG Module Names" subregistry [RFC6020] within bandwidth type
             is set to 'bw-per-cos'.";
        }
        leaf cos-id {
          when "derived-from-or-self(../type, "
             + "'l3vpn-ntw:bw-per-cos')" {
            description
              "Relevant when 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

9.  Security Considerations

   The YANG module specified in this document defines bandwidth type is set to
               'bw-per-cos'.";
          }
          type uint8;
          description
            "Identifier of the CoS, indicated by DSCP or a schema for data
   that
             CE-VLAN CoS (802.1p) value in the service frame.
             If the bandwidth type is designed set to 'bw-per-cos',
             the CoS ID MUST also be accessed via network management protocols such
   as NETCONF [RFC6241] or RESTCONF [RFC8040] .  The lowest NETCONF
   layer specified.";
        }
        leaf vpn-id {
          when "derived-from-or-self(../type, "
             + "'l3vpn-ntw:bw-per-svc')" {
            description
              "Relevant when the bandwidth type is
               set as bandwidth per VPN service.";
          }
          type l3vpn-svc:svc-id;
          description
            "Identifies the secure transport layer, and target VPN.  If the mandatory-to-implement
   secure transport bandwidth
             type is Secure Shell (SSH) [RFC6242]. set as bandwidth per VPN service, the
             vpn-id MUST be specified.";
        }
        leaf cir {
          type uint64;
          units "bps";
          mandatory true;
          description
            "Committed Information Rate.  The lowest
   RESTCONF layer is HTTPS, and maximum number
             of bits that a port can receive or send over
             an interface in one second.";
        }
        leaf cbs {
          type uint64;
          units "bps";
          mandatory true;
          description
            "Committed Burst Size (CBS).  Controls the mandatory-to-implement secure
   transport bursty
             nature of the traffic.  Traffic that does not
             use the configured Committed Information Rate
             (CIR) accumulates credits until the credits
             reach the configured CBS.";
        }
        leaf eir {
          type uint64;
          units "bps";
          description
            "Excess Information Rate (EIR), i.e., excess frame
             delivery allowed that is TLS [RFC8466]. not subject to an SLA.
             The Network Configuration Access Control Model (NACM) [RFC8341]
   provides traffic rate can be limited by 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. EIR.";
        }
        leaf ebs {
          type uint64;
          units "bps";
          description
            "Excess Burst Size (EBS).  The ietf-l3vpn-ntw module bandwidth available
             for burst traffic from the EBS is used subject to manage L3 VPNs in a service
   provider backbone network.  Hence, the module can be used
             amount of bandwidth that is accumulated during
             periods when traffic allocated by the EIR
             policy is not used.";
        }
        leaf pir {
          type uint64;
          units "bps";
          description
            "Peak Information Rate, i.e., maximum frame
             delivery allowed.  It is equal to request,
   modify, or retrieve L3VPN services.  For example, less
             than the creation sum of a
   vpn-service leaf instance triggers the creation of an L3 VPN Service
   in a Service Provider Network.

   Due to CIR and the foreseen use EIR.";
        }
        leaf pbs {
          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).";
      }
      description
        "From the YANG module, there are a number customer site's perspective, the service
         input/output bandwidth of
   data nodes defined in this YANG module that are writable/creatable/
   deletable (i.e., config true, which is the default).  These data
   nodes MAY be considered sensitive connection or vulnerable in some network
   environments.  Write operations (e.g., edit-config) and delete
   operations
         download/upload bandwidth from the SP/site
         to these data nodes without proper protection or
   authentication can have a negative effect on network operations.
   These are the subtrees site/SP.";

    }
    description
      " ";
  }

  grouping status-params {
    container status {
      leaf admin-enabled {
        type boolean;
        description
          "Administrative Status UP/DOWN";
      }
      leaf oper-status {
        type operational-type;
        config false;
        description
          "Operations status";
      }
      description
        "";
    }
    description
      "Grouping used to join operational and data nodes administrative status
       is re used in the Site Network Acess and their sensitivity/
   vulnerability in the ietf-l3vpn-ntw module:

   o  vpn-service: An attacker who is able VPN-Node";
  }

  /* Parameters related to access network nodes can
      undertake various attacks, such as deleting a running L3 VPN
      Service, interrupting all the traffic of a client.  In addition,
      an attacker may modify vpn-nodes (VRF config.) */

  grouping vpn-nodes-params {
    container vpn-nodes {
      description
        "";
      list vpn-node {
        key "ne-id";
        leaf vpn-node-id {
          type union {
            type l3vpn-svc:svc-id;
            type uint32;
          }
          description
            "Type STRING or NUMBER Serivice-Id";
        }
        leaf local-autonomous-system {
          type inet:as-number;
          description
            "Provider AS number in case the attributes customer
             requests BGP routing.";
        }
        leaf description {
          type string;
          description
            "Textual description of a running service (e.g.,
      QoS, bandwidth, routing protocols), leading to malfunctioning VPN node.";
        }
        leaf ne-id {
          type string;
          description
            "";
        }
        leaf router-id {
          type inet:ip-address;
          description
            "router-id information can be ipv4/6 addresses";
        }
        leaf address-family {
          type l3vpn-svc:address-family;
          description
            "Address family used for router-id information.";
        }
        leaf node-role {
          type identityref {
            base l3vpn-svc:site-role;
          }
          default "l3vpn-svc:any-to-any-role";
          description
            "Role of the service and therefore vpn-node in the IP VPN.";
        }
        uses rt-rd;
        uses status-params;
        uses net-acc;
        uses site-maximum-routes;
        uses vpn-service-multicast;
        leaf node-ie-profile {
          type leafref {
            path "/l3vpn-ntw/vpn-services/"
               + "vpn-service/ie-profiles/ie-profile/ie-profile-id";
          }
          description
            "";
        }
        description
          "";
      }
    }
    description
      "Grouping to SLA violations.  In addition, an
      attacker could attempt define VRF-specific configuration.";
  }
  /* Parameters related to create a L3 VPN Service.  Such activity
      can be detected by monitoring import and export profiles (RTs RDs.) */

  grouping ie-profiles-params {
    container ie-profiles {
      list ie-profile {
        key "ie-profile-id";
        leaf ie-profile-id {
          type string;
          description
            "";
        }
        uses rt-rd;
        description
          "";
      }
      description
        "";
    }
    description
      "Grouping to specify rules for route import and tracking network configuration
      changes.

   o  COMPLETE rest export";
  }

  grouping pseudowire-params {
    container pseudowire {
      /*leaf far-end {*/
      /*  description "IP of critical data nodes and subtrees

   Some the remote peer of the readable data nodes in this YANG module may be considered
   sensitive or vulnerable in some network environments.  It is thus
   important to control read access (e.g., via get, get-config, pseudowire.";*/
      /*  type inet:ip-address;*/
      /*}*/
      leaf vcid {
        type uint32;
        description
          "PW or
   notification) to these data nodes.  These are VC identifier.";
      }
      leaf far-end {
        type union {
          type uint32;
          type inet:ipv4-address;
        }
        description
          "SDP/Far End/LDP Neighbour reference.";
      }
      description
        "Pseudowire termination parameters";
    }
    container vpls {
      leaf vcid {
        type union {
          type uint32;
          type string;
        }
        description
          "VCID identifier,IRB/RVPPLs interface
           supported using string
           format.";
      }
      leaf far-end {
        type union {
          type uint32;
          type inet:ipv4-address;
        }
        description
          "SDP/Far End/LDP Neighbour reference.";
      }
      description
        "Pseudowire termination parameters";
    }
    description
      "Grouping pseudowire termination parameters";
  }

  grouping security-params {
    container security {
      leaf auth-key {
        type string;
        description
          "MD5 authentication password for the subtrees and data
   nodes and their sensitivity/vulnerability:

   o  customer-name and ip-connection: An attacker can retrieve privacy-
      related information which can be used to track connection towards the
           customer edge.";
      }
      description
        "Container for aggregating any security parameter for routing
         sessions between a customer.
      Disclosing such information may be considered as PE and a violation of CE.";
    }
    description
      "Grouping to define security parameters";
  }

  grouping ethernet-params {
    container connection {
      leaf encapsulation-type {
        type identityref {
          base encapsulation-type;
        }
        default "untagged-int";
        description
          "Encapsulation type.  By default, the customer-provider trust relationship.

   Summing up,
           encapsulation type is set to 'untagged'.";

      }
      container logical-interface {
        leaf peer-reference {
          type uint32;
          description
            "Specify the foreseen risks associated logical peer interface.";
        }
        description
          "Reference of using the l3vpn-ntw module can be
   clasified into:

   o  Malicious clients attempting to delete or modify services

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

   o  Unauthorized clients attempting to read service information

10.  Implementation Status

10.1.  Nokia Implementation

   Nokia has a draft implementation logical interface type.";
      }
      container tagged-interface {
        leaf type {
          type identityref {
            base tagged-inf-type;
          }
          default "priority-tagged";
          description
            "Tagged interface type.  By default,
             the type of the IETF L3NM model.

   The implementation is a prototype and tagged interface is currently being planned for
   production.

   Nokia NSP (Network Services Platform) supports integration
             'priority-tagged'.";
        }
        container dot1q-vlan-tagged {
          when "derived-from-or-self(../type, "
             + "'l3vpn-ntw:dot1q')" {
            description
              "Only applies when the type of
   standard models with the Intent Manager framework.  NSP platform
   provides hot pluggable model definitions and implementations which
   would enable defining models where standardization tagged
               interface is in progress or
   non-existent.  With pluggable architecture for model and
   implementation injections, NSP also serves as a Multi-Layer, Multi-
   Domain controller.

   The Nokia implementation 'dot1q'.";
          }
          if-feature "dot1q";
          leaf tag-type {
            type identityref {
              base tag-type;
            }
            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 L3NM covers, the following
   a) RESTConf support

   b) Configuration of L3 IP VPN Services.  Create/Get/Query/Delete
   supported on tagged
               interface is 'priority-tagged'.";
          }
          leaf tag-type {
            type identityref {
              base tag-type;
            }
            default "c-vlan";
            description
              "Tag type.  By default, the tag type is
               'c-vlan'.";
          }
          description
            "Priority tagged.";
        }
        container qinq {
          when "derived-from-or-self(../type, "
             + "'l3vpn-ntw:qinq')" {
            description
              "Only applies when the following operations.

   * Site

   * Site-Bearer

   * VpnService

   * IEProfile

   * VpnNode

   * Site Network Access

   * Site Attachments

   c) Supports translations to type of the Device Model (Standard /
   Properietary)

   draft-ietf-opsawg-l3sm-l3nm-00

   The current implementation tagged
               interface is proprietary, so under no terms 'qinq'.";
          }
          if-feature "qinq";
          leaf tag-type {
            type identityref {
              base tag-type;
            }
            default "c-s-vlan";
            description
              "Tag type.  By default, the
   current implementation can be used.

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

10.2.  Huawei Implementation

   The organization responsible for tag type is
               'c-s-vlan'.";
          }
          leaf svlan-id {
            type uint16;
            mandatory true;
            description
              "SVLAN identifier.";
          }
          leaf cvlan-id {
            type uint16;
            mandatory true;
            description
              "CVLAN identifier.";
          }
          description
            "QinQ.";

        }
        container qinany {
          when "derived-from-or-self(../type, "
             + "'l3vpn-ntw:qinany')" {
            description
              "Only applies when the implementation, if any.

   Huawei Technologies Co.,Ltd.

   The implementation's name and/or a link to a web page where type of the
   implementation or a tagged
               interface is 'qinany'.";
          }
          if-feature "qinany";
          leaf tag-type {
            type identityref {
              base tag-type;
            }
            default "s-vlan";
            description of it can be found.

   NCE V1R19C00

   A brief general description.

   This section provides an implementation report summary for Layer 3
   VPN Network Model.  Layer 3 VPN Network Model
              "Tag type.  By default, the tag type is available at:
   https://tools.ietf.org/html/draft-ietf-opsawg-l3sm-l3nm-00
   The implementation's level
               's-vlan'.";
          }
          leaf svlan-id {
            type uint16;
            mandatory true;
            description
              "Service VLAN ID.";
          }
          description
            "Container for QinAny.";
        }
        container vxlan {
          when "derived-from-or-self(../type, "
             + "'l3vpn-ntw:vxlan')" {
            description
              "Only applies when the type of maturity: research, prototype, alpha,
   beta, production, widely used, etc.

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

   Coverage: which parts of 'vxlan'.";
          }
          if-feature "vxlan";
          leaf vni-id {
            type uint32;
            mandatory true;
            description
              "VXLAN Network Identifier (VNI).";
          }
          leaf peer-mode {
            type identityref {
              base vxlan-peer-mode;
            }
            default "static-mode";
            description
              "Specifies the protocol specification are implemented.

   We have implemented pruned L3NM model with VXLAN access mode.  By default,
               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 peer mode is set to 'static-mode'.";
          }
          list peer-list {
            key "peer-ip";
            leaf peer-ip {
              type inet:ip-address;
              description
                "Peer IP.";
            }
            description
              "List of peer IP addresses.";
          }
          description
            "QinQ.";
        }
        description
          "Container for tagged interfaces.";
      }
      container 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
                  |  |     +--rw provider-address?   inet:ipv4-address
                  |  |     +--rw customer-address?   inet:ipv4-address
                  |  |     +--rw prefix-length?      uint8
                  +--rw service
                  |  +--rw qos {qos}?
                  |  |  +--rw qos-profile
                  |  |     +--rw (qos-profile)?
                  |  |        +--:(standard)
                  |  |        |  +--rw profile?   leafreaf
                  +--rw routing-protocols
                  |  +--rw routing-protocol* [type]
                  |     +--rw {
        leaf bearer-reference {
          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.";
      }
      description
        "Encapsulation types";
    }
    description
      "Grouping to define encapsulation types";
  }

  grouping rt-rd {
    leaf rd {
      type rt-types:route-distinguisher;
      description
        "";
    }
    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 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 {
        type int8;
        description
          "Identifies each VPN Target";
      }
      list route-targets {
        key "route-target";
        leaf route-target {
          type rt-types:route-target;
          description
            "Route Target value";
        }
        description
          "List of Route Targets.";
      }
      leaf route-target-type {
        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 rt-types:route-target-type;
        mandatory true;
        description
          "Import/export type of the Route Target.";
      }
      description
        "l3vpn route targets. AND/OR Operations are available
         based on the RTs assigment";
    }
    reference
      "RFC4364: BGP/MPLS IP Virtual Private Networks (VPNs)
       RFC4664: Framework for Layer 2 Virtual Private Networks
       (L2VPNs)";
    container vpn-policies {
      description
        "";
      leaf import-policy {
        type leafref {
          path "/l3vpn-ntw/vpn-profiles/valid-provider-identifiers/"
             + "routing-profile-identifier/id";
        }
        description
          "Reference to a VRF import policy.";
      }
      leaf export-policy {
        type leafref {
          path "/l3vpn-ntw/vpn-profiles/valid-provider-identifiers/"
             + "routing-profile-identifier/id";
        }
        description
          "Reference to a VRF export policy.";
      }
    }
  }

  grouping net-acc {
    container vpn-network-accesses {
      list vpn-network-access {
        key "id";
        leaf id {
          type l3vpn-svc:svc-id;
          description
            "Identifier for the access.";
        }
        leaf port-id {
          type l3vpn-svc:svc-id;
          description
            "Identifier for the network access.";
        }
        leaf description {
          type string;
          description
            "Textual description of a VPN service.";
        }
        uses site-network-access-top-level-cfg;
        description
          "List of accesses for a site.";
      }
      description
        "List of accesses for a site.";
    }
    description
      "Main block of the Network Access.";
  }

  /* Main Blocks */

  container l3vpn-ntw {
    container vpn-profiles {
      uses vpn-profile-cfg;
      description
        "Container for VPN Profiles.";
    }
    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 service configuration.";
  }
}
<CODE ENDS>

                                 Figure 16

   Use Cases we 24

11.  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.  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 module is used to manage L3 VPNs in a service
   provider backbone network.  Hence, the module can be used to request,
   modify, or retrieve L3VPN services.  For example, the creation of a
   vpn-service leaf instance triggers the creation of an L3 VPN Service
   in a Service Provider Network.

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

   (a).Create a negative effect on network operations.
   These are the subtrees and data nodes and their sensitivity/
   vulnerability in the ietf-l3vpn-ntw module:

   o  vpn-service: An attacker who is able to access network nodes can
      undertake various attacks, such as deleting a running L3 VPN

   (b).Create Site

   (c).Create/add bearers
      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.  Such activity
      can be detected by monitoring and tracking network configuration
      changes.

   o  COMPLETE rest of critical data nodes and subtrees

   Some of the readable data nodes in this YANG module may be considered
   sensitive or vulnerable in some network environments.  It is thus
   important to control read access (e.g., via get, get-config, or
   notification) to these data nodes.  These are the subtrees and data
   nodes and their sensitivity/vulnerability:

   o  customer-name and ip-connection: An attacker can retrieve privacy-
      related information which can be used to an existing Site

   (d).Create/Include Site Network Access into VPN nodes.

   Version compatibility: what version/versions track a customer.
      Disclosing such information may be considered as a violation of
      the Internet-Draft
   are known to be implemented.

   draft-ietf-opsawg-l3sm-l3nm-00

   Licensing: customer-provider trust relationship.

   Summing up, the terms under which foreseen risks of using the implementation l3vpn-ntw module can be used.  For
   example: proprietary, royalty licensing, freely distributable with
   acknowledgement (BSD style), freely distributable with requirement
   clasified into:

   o  Malicious clients attempting to
   redistribute source (General Public License (GPL) style), and other
   (specify).

   Not available yet.

   Implementation experience: any useful delete or modify services

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

   o  Unauthorized clients attempting to read service information

13.  Acknowledgements

   Thanks to Adrian Farrel and Miguel Cros for the implementers
   want suggestions on the
   document.  Thanks to share with Philip Eardlay for the community.

   Contact information: ideally a person's name and email address, but
   possibly just a URL or review.  Lots of thanks
   for the discussions on opsawg mailing list. 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.  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 (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
   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.  References

15.1.  Normative References

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

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
   interoperability.

   Nokia

10.3.  Infinera Implementation

   Infinera has a draft implementation of
              the IETF L3NM model.  The
   implementation is in beta state and is currently being tested 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
   integrated with other suppliers controllers supporting this same
   model.  Infinera is supporting 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 L3NM model in its Transcend
   Maestro Multi-layer, Multi-domain Controller.

   The Infinera implementation of L3NM covers discovery NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              <https://www.rfc-editor.org/info/rfc6242>.

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

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

   [RFC8174]  Leiba, B., "Ambiguity of IP VPN services, and is supporting both North-Bound
   (server) and South-Bound (client) functionality.  Versions 01 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 02
   of the model are supported.

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

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

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

11.  Acknowledgements

   Thanks to Adrian Farrel 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 Miguel Cros L. Jalil, "A YANG
              Data Model for the suggestions on the
   document.  Thanks to Philip Eardlay 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.  Informative References

   [I-D.evenwu-opsawg-yang-composed-vpn]
              Even, R., Bo, W., Wu, Q., and Y. Cheng, "YANG Data Model
              for the review.  Lots of thanks 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 the discussions on opsawg mailing list Service Provider Networks", draft-ietf-idr-
              bgp-model-08 (work in progress), February 2020.

   [I-D.ietf-rtgwg-qos-model]
              Choudhary, A., Jethanandani, M., Strahle, N., Aries, E.,
              and at IETF meeting.

   This work was supported I. Chen, "YANG Model for QoS", draft-ietf-rtgwg-qos-
              model-00 (work in part by the European Commission funded
   H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727).

12.  Contributors

   Samier Barguil
   Telefonica
   Email: samier.barguilgiraldo.ext@telefonica.com

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

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

   Qin Wu
   Huawei
   Email: bill.wu@huawei.com>
   Mohamed Boucadair
   Orange
   Email: mohamed.boucadair@orange.com>

   Stephane Litkowski
   Cisco
   Email: slitkows@cisco.com>

13.  References

13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words progress), October 2019.

   [I-D.liu-pim-yang]
              Liu, Y., Guo, F., and M. Sivakumar, "YANG Data Model for use
              PIM", draft-liu-pim-yang-01 (work in RFCs to Indicate
              Requirement Levels", BCP 14, progress), March
              2015.

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

   [RFC3688]  Mealling, 2005,
              <https://www.rfc-editor.org/info/rfc4026>.

   [RFC4176]  El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., "The IETF XML Registry", BCP 81, 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>.

   [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 3688, 8309, DOI 10.17487/RFC3688, 10.17487/RFC8309, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC6020] 2018,
              <https://www.rfc-editor.org/info/rfc8309>.

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

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, 10.17487/RFC8340, March 2018,
              <https://www.rfc-editor.org/info/rfc8340>.

   [RFC8345]  Clemm, A., Medved, J., Ed., Varga, R., Bahadur, N.,
              Ananthakrishnan, H., and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", X. Liu, "A YANG Data Model for
              Network Topologies", RFC 6241, 8345, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

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

   [RFC7950]  Bjorklund, M., 10.17487/RFC8349, March 2018,
              <https://www.rfc-editor.org/info/rfc8349>.

   [RFC8453]  Ceccarelli, D., Ed. and Y. Lee, Ed., "The YANG 1.1 Data Modeling Language", "Framework for
              Abstraction and Control of TE Networks (ACTN)", RFC 7950, 8453,
              DOI 10.17487/RFC7950, 10.17487/RFC8453, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

   [RFC8040]  Bierman, A., Bjorklund, 2018,
              <https://www.rfc-editor.org/info/rfc8453>.

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

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

   [RFC8341]  Bierman, 10.17487/RFC8519, March 2019,
              <https://www.rfc-editor.org/info/rfc8519>.

Appendix A.  Implementation Status

A.1.  Nokia Implementation

   Nokia has a draft implementation of the IETF L3NM model.

   The implementation is a prototype and is currently being planned for
   production.

   Nokia NSP (Network Services Platform) supports integration of
   standard models with the Intent Manager framework.  NSP platform
   provides hot pluggable model definitions and implementations which
   would enable defining models where standardization is in progress or
   non-existent.  With pluggable architecture for model and M. Bjorklund, "Network
   implementation injections, NSP also serves as a Multi-Layer, Multi-
   Domain controller.

   The Nokia implementation of L3NM covers, 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 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

   * Site Attachments

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

   draft-ietf-opsawg-l3sm-l3nm-00

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

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

A.2.  Huawei Implementation

   The organization responsible for the implementation, if any.

   Huawei Technologies Co.,Ltd.

   The implementation's name and/or a link to a web page where 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 2 Virtual Private 3
   VPN Network (L2VPN)
              Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October
              2018, <https://www.rfc-editor.org/info/rfc8466>.

13.2.  Informative References

   [RFC4026]  Andersson, L. and T. Madsen, "Provider Provisioned Virtual
              Private Model.  Layer 3 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
                  |  |     +--rw provider-address?   inet:ipv4-address
                  |  |     +--rw customer-address?   inet:ipv4-address
                  |  |     +--rw prefix-length?      uint8
                  +--rw 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

                                 Figure 25

   Use Cases we have implemented include:

   (a).Create VPN

   (b).Create Site

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

   (d).Create/Include Site Network (VPN) Terminology", RFC 4026,
              DOI 10.17487/RFC4026, March 2005,
              <https://www.rfc-editor.org/info/rfc4026>.

   [RFC4076]  Chown, T., Venaas, S., Access into VPN nodes.

   Version compatibility: what version/versions 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 A. Vijayabhaskar, "Renumbering
              Requirements for Stateless Dynamic Host Configuration
              Protocol for IPv6 (DHCPv6)", RFC 4076,
              DOI 10.17487/RFC4076, May 2005,
              <https://www.rfc-editor.org/info/rfc4076>.

   [RFC4176]  El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., other
   (specify).

   Not available yet.

   Implementation experience: any useful information the implementers
   want to share with the community.

   Contact information: ideally a person's name and A. Gonguet, "Framework 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 Layer 3 Virtual Private
              Networks (L3VPN) Operations
   interoperability.

   Nokia

A.3.  Infinera Implementation

   Infinera has a draft implementation of the IETF L3NM model.  The
   implementation is in beta state and Management", RFC 4176,
              DOI 10.17487/RFC4176, October 2005,
              <https://www.rfc-editor.org/info/rfc4176>.

   [RFC8299]  Wu, Q., Ed., Litkowski, S., Tomotaki, L., is currently being tested 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.,
   integrated with other suppliers controllers supporting this same
   model.  Infinera is supporting the L3NM model in its Transcend
   Maestro Multi-layer, Multi-domain Controller.

   The Infinera implementation of L3NM covers discovery and A. Farrel, "Service Models
              Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
              <https://www.rfc-editor.org/info/rfc8309>.

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

   [RFC8453]  Ceccarelli, D., Ed. is supporting both North-Bound
   (server) and Y. Lee, Ed., "Framework for
              Abstraction South-Bound (client) functionality.  Versions 01 and Control 02
   of TE Networks (ACTN)", RFC 8453,
              DOI 10.17487/RFC8453, August 2018,
              <https://www.rfc-editor.org/info/rfc8453>. the model are supported.

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

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

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

Authors' Addresses

   Alejandro Aguado
   Nokia

   Samier Barguil
   Telefonica
   Madrid
   ES

   Email: alejandro.aguado_martin@nokia.com samier.barguilgiraldo.ext@telefonica.com

   Oscar Gonzalez de Dios (editor)
   Telefonica
   Madrid
   ES

   Email: oscar.gonzalezdedios@telefonica.com

   Victor Lopez
   Telefonica
   Madrid
   ES

   Email: victor.lopezalvarez@telefonica.com

   Daniel Voyer
   Bell Canada
   CA
   Mohamed Boucadair
   Orange
   FR

   Email: daniel.voyer@bell.ca "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