L3SM Working Group
Internet Engineering Task Force (IETF)                      S. Litkowski
Internet-Draft
Request for Comments: 8049                      Orange Business Services
Intended status:
Category: Standards Track                                    L. Tomotaki
Expires: May 8, 2017
ISSN: 2070-1721                                                  Verizon
                                                                K. Ogaki
                                                        KDDI
                                                       November 04, 2016 Corporation
                                                           February 2017

               YANG Data Model for L3VPN service delivery
                 draft-ietf-l3sm-l3vpn-service-model-19 Service Delivery

Abstract

   This document defines a YANG data model that can be used for
   communication between customers and network operators and to deliver
   a Layer 3 Provider Provisioned provider-provisioned VPN service.  The  This document is limited
   to the BGP PE-based VPNs as described in [RFC4026], [RFC4110] RFCs 4026, 4110, and
   [RFC4364]. 4364.  This
   model is intended to be instantiated at the management system to
   deliver the overall service.  This model  It is not a configuration model to be
   used directly on network elements.  This model provides an abstracted
   view of the Layer 3 IPVPN IP VPN service configuration components.  It will
   be up to a the management system to take this model as an input and use
   specific configurations configuration models to configure the different network
   elements to deliver the service.  How the configuration of network
   elements is done is out of scope of the
   document.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in for this
   document are to be interpreted as described in [RFC2119]. document.

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 an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of six months RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 8, 2017.
   http://www.rfc-editor.org/info/rfc8049.

Copyright Notice

   Copyright (c) 2016 2017 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
   (http://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  . . . . . . . . . . . . . . . . . . . . . . . .   4 ....................................................4
      1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . .   4 ................................................4
      1.2. Requirements Language ......................................5
      1.3. Tree diagram  . . . . . . . . . . . . . . . . . . . . . .   5 Diagrams ..............................................5
   2. Acronyms  . . . . . . . . . . . . . . . . . . . . . . . . . .   5 ........................................................5
   3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   7 .....................................................7
   4. Layer 3 IP VPN service model  . . . . . . . . . . . . . . . .   7 Service Model ....................................8
   5. Service data model usage  . . . . . . . . . . . . . . . . . .   8 Data Model Usage ........................................9
   6. Design of the Data Model  . . . . . . . . . . . . . . . . . .   9 .......................................10
      6.1. Features and augmentation . . . . . . . . . . . . . . . .  16 Augmentation .................................18
      6.2. VPN service overview  . . . . . . . . . . . . . . . . . .  17 Service Overview ......................................18
           6.2.1. VPN service topology  . . . . . . . . . . . . . . . .  17 Service Topology ...............................18
                  6.2.1.1. Route Target allocation . . . . . . . . . . . . .  17 Allocation ...................19
                  6.2.1.2.  Any to any  . . . . . . . . . . . . . . . . . . .  18 Any-to-Any ................................20
                  6.2.1.3. Hub and Spoke . . . . . . . . . . . . . . . . . .  18 .............................20
                  6.2.1.4. Hub and Spoke disjoint  . . . . . . . . . . . . .  19 Disjoint ....................21
           6.2.2. Cloud access  . . . . . . . . . . . . . . . . . . . .  20 Access .......................................22
           6.2.3. Multicast service . . . . . . . . . . . . . . . . . .  22 Service ..................................24
           6.2.4. Extranet VPNs . . . . . . . . . . . . . . . . . . . .  24 ......................................26
      6.3. Site overview . . . . . . . . . . . . . . . . . . . . . .  25 Overview .............................................27
           6.3.1. Devices and locations . . . . . . . . . . . . . . . .  26 Locations ..............................29
           6.3.2. Site network accesses . . . . . . . . . . . . . . . .  27 Network Accesses ..............................30
                  6.3.2.1. Bearer  . . . . . . . . . . . . . . . . . . . . .  28 ....................................30
                  6.3.2.2. Connection  . . . . . . . . . . . . . . . . . . .  28 ................................31
                  6.3.2.3. Inheritance of parameters between site Parameters Defined at
                           Site Level and site-
                   network-access  . . . . . . . . . . . . . . . . .  29 Site Network Access Level ..32
      6.4. Site role . . . . . . . . . . . . . . . . . . . . . . . .  30 Role .................................................32
      6.5. Site belonging Belonging to multiple Multiple VPNs . . . . . . . . . . . . .  30 ...........................33
           6.5.1. Site vpn flavor . . . . . . . . . . . . . . . . . . .  30 VPN Flavor ....................................33
                  6.5.1.1. Single VPN attachment : Attachment:
                           site-vpn-flavor-single  .  30 ....................33
                  6.5.1.2.  Multi VPN attachment : MultiVPN Attachment:
                           site-vpn-flavor-multi  . .  31 .....................33
                  6.5.1.3.  Sub VPN attachment : SubVPN Attachment: site-vpn-flavor-sub  . . . .  31 ....34
                  6.5.1.4.  NNI : NNI: site-vpn-flavor-nni . . . . . . . . . . . .  33 ..................36
           6.5.2. Attaching a site Site to a VPN . . . . . . . . . . . . . .  34 ..........................37
                  6.5.2.1.  Reference Referencing a VPN . . . . . . . . . . . . . . . . .  35 .........................37
                  6.5.2.2. VPN policy  . . . . . . . . . . . . . . . . . . .  35 Policy ................................38
      6.6. Deciding where Where to connect Connect the site  . . . . . . . . . . .  38 Site ........................40
           6.6.1. Constraint: Device  . . . . . . . . . . . . . . . . .  39 .................................41
           6.6.2.  Constraint/parameter: Constraint/Parameter: Site location . . . . . . . . .  39 Location ................41
           6.6.3.  Constraint/parameter: access type . . . . . . . . . .  41 Constraint/Parameter: Access Type ..................42
           6.6.4. Constraint: access diversity  . . . . . . . . . . . .  41 Access Diversity .......................43
           6.6.5.  Impossible access placement . . . . . . . . . . . . .  47 Infeasible Access Placement ........................49
           6.6.6. Examples of access placement  . . . . . . . . . . . .  48 Access Placement .......................50
                  6.6.6.1. Multihoming . . . . . . . . . . . . . . . . . . .  48 ...............................50
                  6.6.6.2. Site offload  . . . . . . . . . . . . . . . . . .  50 Offload ..............................53
                  6.6.6.3. Parallel links  . . . . . . . . . . . . . . . . .  56 Links ............................59
                  6.6.6.4. SubVPN with multihoming . . . . . . . . . . . . .  57 Multihoming ...................60
           6.6.7. Route Distinguisher and VRF allocation  . . . . . . .  61 Allocation .............64
      6.7. Site network access availability  . . . . . . . . . . . .  62 Network Access Availability ..........................64
      6.8. Traffic protection  . . . . . . . . . . . . . . . . . . .  63 Protection ........................................66
      6.9. Security  . . . . . . . . . . . . . . . . . . . . . . . .  64 ..................................................66
           6.9.1. Authentication  . . . . . . . . . . . . . . . . . . .  64 .....................................67
           6.9.2. Encryption  . . . . . . . . . . . . . . . . . . . . .  64 .........................................67
      6.10. Management  . . . . . . . . . . . . . . . . . . . . . . .  65 ...............................................68
      6.11. Routing protocols . . . . . . . . . . . . . . . . . . . .  66 Protocols ........................................68
           6.11.1. Handling of Dual stack handling  . . . . . . . . . . . . . . . .  66 Stack ............................69
           6.11.2.  Direct LAN connection onto Directly Connected to SP network  . . . . . . .  67 Network ..............70
           6.11.3.  Direct LAN connection onto Directly Connected to SP network Network with
                redundancy . . . . . . . . . . . . . . . . . . . . .  67
                   Redundancy ........................................70
           6.11.4. Static routing . . . . . . . . . . . . . . . . . . .  68 Routing ....................................70
           6.11.5. RIP routing  . . . . . . . . . . . . . . . . . . . .  68 Routing .......................................71
           6.11.6. OSPF routing . . . . . . . . . . . . . . . . . . . .  68 Routing ......................................71
           6.11.7. BGP routing  . . . . . . . . . . . . . . . . . . . .  70 Routing .......................................73
      6.12. Service . . . . . . . . . . . . . . . . . . . . . . . . .  71 ..................................................75
           6.12.1. Bandwidth  . . . . . . . . . . . . . . . . . . . . .  71 .........................................75
           6.12.2. QoS  . . . . . . . . . . . . . . . . . . . . . . . .  72 ...............................................75
                  6.12.2.1. QoS classification . . . . . . . . . . . . . . .  72 Classification .......................75
                  6.12.2.2. QoS profile  . . . . . . . . . . . . . . . . . .  75 Profile ..............................78
           6.12.3. Multicast  . . . . . . . . . . . . . . . . . . . . .  79 .........................................81
      6.13. Enhanced VPN features . . . . . . . . . . . . . . . . . .  79 Features ....................................82
           6.13.1.  Carrier's Carrier  . . . . . . . . . . . . . . . . .  79 Carriers' Carriers ................................82
      6.14. External ID references  . . . . . . . . . . . . . . . . .  81 References ...................................83
      6.15. Defining NNIs . . . . . . . . . . . . . . . . . . . . . .  81 ............................................83
           6.15.1. Defining an NNI with option the Option A flavor  . . . . . . . . .  83 Flavor ..........85
           6.15.2. Defining an NNI with option the Option B flavor  . . . . . . . . .  86 Flavor ..........88
           6.15.3. Defining an NNI with option the Option C flavor  . . . . . . . . .  88 Flavor ..........91
   7. Service model usage example . . . . . . . . . . . . . . . . .  90 Model Usage Example ....................................92
   8. Interaction with Other YANG Modules . . . . . . . . . . . . .  95 ............................98
   9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . .  99 ...................................................102
   10. Security Considerations . . . . . . . . . . . . . . . . . . . 153 ......................................154
   11. Contribution  . . . . . . . . . . . . . . . . . . . . . . . . 154
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 154
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 154
   14. Change Log  . . . . . . . . . . . . . . . . . . . . . . . . . 154
     14.1.  Changes between versions -18 and-19  . . . . . . . . . . 154
     14.2.  Changes between versions -17 and-18  . . . . . . . . . . 155
     14.3.  Changes between versions -16 and-17  . . . . . . . . . . 155
     14.4.  Changes between versions -15 and-16  . . . . . . . . . . 156
     14.5.  Changes between versions -13 and-14  . . . . . . . . . . 156
     14.6.  Changes between versions -12 and-13  . . . . . . . . . . 156
     14.7.  Changes between versions -11 and-12  . . . . . . . . . . 156
     14.8.  Changes between versions -09 and-10  . . . . . . . . . . 156
     14.9.  Changes between versions -08 and-09  . . . . . . . . . . 157
     14.10. Changes between versions -07 and-08  . . . . . . . . . . 157
     14.11. Changes between versions -06 and-07  . . . . . . . . . . 157
     14.12. Changes between versions -05 and-06  . . . . . . . . . . 157
     14.13. Changes between versions -04 and-05  . . . . . . . . . . 158
     14.14. Changes between versions -02 and-03  . . . . . . . . . . 158
     14.15. Changes between versions -01 and-02  . . . . . . . . . . 158
     14.16. Changes between versions -00 and-01  . . . . . . . . . . 159
   15. ..........................................155
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . . 159
     15.1. ...................................................155
      12.1. Normative References . . . . . . . . . . . . . . . . . . 159
     15.2. ....................................155
      12.2. Informative References . . . . . . . . . . . . . . . . . 161 ..................................157
   Acknowledgements .................................................157
   Contributors .....................................................157
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 161 ...............................................157

1.  Introduction

   This document defines a Layer 3 VPN service data model written in
   YANG.  The model defines service configuration elements that can be
   used in communication protocols between customers and network
   operators.  Those elements can also be used also as input to automated
   control and configuration applications.

1.1.  Terminology

   The following terms are defined in [RFC6241] and are not redefined
   here:

   o  client

   o  configuration data

   o  server

   o  state data

   The following terms are defined in [RFC7950] and are not redefined
   here:

   o  augment

   o  data model

   o  data node
   The terminology for describing YANG data models is found in
   [RFC7950].

   This document presents some configuration examples using XML
   representation.

1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.3.  Tree diagram Diagrams

   A simplified graphical representation of the data model is presented
   in Section 6.

   The meaning meanings of the symbols in these diagrams is are as follows:

   o  Brackets "[" and "]" enclose list keys.

   o  Curly braces "{" and "}" contain names of optional features that
      make the corresponding node conditional.

   o  Abbreviations before data node names: "rw" means configuration
      data (read-write), and "ro" means state data (read-only).

   o  Symbols after data node names: "?" means an optional node node, and "*"
      denotes a "list" or "leaf-list".

   o  Parentheses enclose choice and case nodes, and case nodes are also
      marked with a colon (":").

   o  Ellipsis ("...") stands for contents of subtrees that are not
      shown.

2.  Acronyms

   AAA: Authentication, Authorization, and Accounting.

   ACL: Access Control List.

   ADSL: Asymmetric DSL.

   AH: Authentication Header.

   AS: Autonomous System.

   ASBR: Autonomous System Border Router.

   ASM: Any-Source Multicast.

   BAS: Broadband Access Switch.

   BFD: Bidirectional Forwarding Detection.

   BGP: Border Gateway Protocol.

   BSR: Bootstrap Router.

   CE: Customer Edge.

   CLI: Command Line Interface.

   CsC: Carrier's Carrier. Carriers' Carriers.

   CSP: Cloud Service Provider.

   DHCP: Dynamic Host Configuration Protocol.

   DSLAM: Digital Subscriber Line Access Multiplexer.

   ESP: Encapsulating Security Payload.

   GRE: Generic Routing Encapsulation.

   IGMP: Internet Group Management Protocol.

   LAN: Local Area Network.

   MLD: Multicast Listener Discovery.

   MTU: Maximum Transmission Unit.

   NAT: Network Address Translation.

      NNI: Network to

   NETCONF: Network Configuration Protocol.

   NNI: Network-to-Network Interface.

   OAM: Operation Administration Operations, Administration, and Management. Maintenance.

   OSPF: Open Shortest Path First.

   OSS: Operations Support System.

   PE: Provider Edge.

      POP: Point Of Presence.

   PIM: Protocol Independent Multicast.

   POP: Point of Presence.

   QoS: Quality Of of Service.

   RD: Route Distinguisher.

   RIP: Routing Information Protocol.

      RD: Route Distinguisher.

   RP: Rendez-vous Rendezvous Point.

   RT: Route Target.

   SFTP: Secure FTP.

   SLA: Service Level Agreement.

   SLAAC: Stateless Address AutoConfiguration. Autoconfiguration.

   SP: Service Provider.

   SPT: Shortest Path Tree.

   SSM: Source-Specific Multicast.

   VM: Virtual Machine.

   VPN: Virtual Private Network.

   VRF: VPN Routing and Forwarding.

   VRRP: Virtual Router Redundancy Protocol.

3.  Definitions

   Customer Edge (CE) Device: Equipment that A CE is equipment dedicated to a
   particular customer and customer; it is directly connected (at layer Layer 3) to one or
   more PE devices via attachment circuits.  A CE is usually located at
   the customer premises, premises and is usually dedicated to a single VPN,
   although it may support multiple VPNs if each one has separate
   attachment circuits.

   Provider Edge (PE) Device: Equipment A PE is equipment managed by the Service Provider
   (SP) that SP; it
   can support multiple VPNs for different customers, customers and is directly
   connected (at layer Layer 3) to one or more CE devices via attachment
   circuits.  A PE is usually located at an SP point of presence (PoP) (POP)
   and is managed by the SP.

   PE-Based VPNs: The PE devices know that certain traffic is VPN
   traffic.  They forward the traffic (through tunnels) based on the
   destination IP address of the packet, and optionally on packet and, optionally, based on other
   information in the IP header of the packet.  The PE devices are
   themselves the tunnel endpoints.  The tunnels may make use of various
   encapsulations to send traffic over the SP network (such as, but not
   restricted to, GRE, IP-in-IP, IPsec, or MPLS tunnels).

4.  Layer 3 IP VPN service model Service Model

   A layer Layer 3 IPVPN IP VPN service is a collection of sites that are authorized
   to exchange traffic between each other over a shared IP
   infrastructure.  This layer Layer 3 VPN service model aims at providing a
   common understanding on of how the corresponding IP VPN service is to be
   deployed over the shared infrastructure.  This service model is
   limited to BGP PE-Based PE-based VPNs as described in [RFC4110] [RFC4026], [RFC4110],
   and [RFC4364].

5.  Service data model usage

            L3VPN-SVC Data Model Usage

                l3vpn-svc |
              MODEL
                  Model   |
                          |
                   +------------------+         +-----+
                   |   Orchestration  | < --- > | OSS |
                   +------------------+         +-----+
                      |            |
              +----------------+   |
              | Config manager |   |
              +----------------+   |
                      |            |
                      | Netconf/CLI NETCONF/CLI ...
                      |            |
        +------------------------------------------------+
                             Network

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

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

              Site A                               Site B

   The idea of the L3 IPVPN IP VPN service model is to propose an abstracted
   interface between customers and network operators to manage
   configuration of components of a an L3VPN service.  A typical usage is scenario
   would be to use this model as an input for an orchestration layer who
   that will be responsible to translate for translating it to an orchestrated
   configuration of network elements who that will be part of the service.
   The network elements can be routers, routers but can also be servers (like AAA), and
   AAA); the network's configuration is not limited to these examples.
   The configuration of network elements can be done by via the CLI, or by NETCONF ([RFC6241])/RESTCONF ([I-D.ietf-netconf-restconf])
   NETCONF/RESTCONF [RFC6241] [RFC8040] coupled with specific configuration YANG data models of
   a specific configuration (BGP, VRF, BFD
   ...) BFD, etc.), or any some other way.
   technique, as preferred by the operator.

   The usage of this service model is not limited to this example, example; it
   can be used by any component of the management system but not
   directly by network elements.

6.  Design of the Data Model

   The YANG module is divided in into two main containers : vpn-services,
   sites. containers: "vpn-services"
   and "sites".

   The vpn-service "vpn-service" list under the vpn-services container defines
   global parameters for the VPN service for a specific customer.

   A site "site" is composed of at least one site-network-access and "site-network-access" and, in
   the case of multihoming, may have multiple site-network-access in case of multihoming.
   points.  The site-
   network-access site-network-access attachment is done through a bearer
   "bearer" with an IP
   connection "ip-connection" on top.  The bearer refers to
   properties of the attachment that are below layer 3 Layer 3, while the
   connection refers to layer 3
   protocol properties oriented properties. to the Layer 3 protocol.
   The bearer may be allocated dynamically by the service provider SP, and the customer
   may provide some constraints or parameters to drive the placement. placement of
   the access.

   Authorization of traffic exchange is done through what we call a VPN
   policy or VPN service topology defining routing exchange rules
   between sites.

   The figure below describe describes the overall structure of the YANG module:

   module: ietf-l3vpn-svc
     +--rw l3vpn-svc
      +--rw vpn-services
      | +--rw vpn-service* [vpn-id]
      |   +--rw vpn-id         svc-id
      |   +--rw customer-name?     string
      |   +--rw vpn-service-topology?  identityref
      |   +--rw cloud-accesses {cloud-access}?
      |   | +--rw cloud-access* [cloud-identifier]
      |   |   +--rw cloud-identifier    string
      |   |   +--rw (list-flavor)?
      |   |   | +--:(permit-any)
      |   |   | | +--rw permit-any?      empty
      |   |   | +--:(deny-any-except)
      |   |   | | +--rw permit-site*      leafref
      |   |   | +--:(permit-any-except)
      |   |   |   +--rw deny-site*       leafref
      |   |   +--rw authorized-sites
      |   |   | +--rw authorized-site* [site-id]
      |   |   |   +--rw site-id  leafref
      |   |   +--rw denied-sites
      |   |   | +--rw denied-site* [site-id]
      |   |   |   +--rw site-id  leafref
      |   |   +--rw address-translation
      |   |    +--rw nat44
      |   |      +--rw enabled?         boolean
      |   |      +--rw nat44-customer-address?  inet:ipv4-address
      |   +--rw multicast {multicast}?
      |   | +--rw 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
      |   |   |   | +--rw enabled?          boolean
      |   |   |   | +--rw rp-redundancy?       boolean
      |   |   |   | +--rw optimal-traffic-delivery?  boolean
      |   |   |   +--rw rp-address?     inet:ip-address
      |   |   |   +--rw groups
      |   |   |    +--rw group* [id]
      |   |   |      +--rw id        uint16
      |   |   |      +--rw (group-format)?
      |   |   |       +--:(startend)
      |   |   |       | +--rw group-start?   inet:ip-address
      |   |   |       | +--rw group-end?    inet:ip-address
      |   |   |       +--:(singleaddress)
      |   |   |         +--rw group-address?  inet:ip-address
      |   |   +--rw rp-discovery
      |   |    +--rw rp-discovery-type?  identityref
      |   |    +--rw bsr-candidates
      |   |      +--rw bsr-candidate-address*  inet:ip-address
      |   +--rw carrierscarrier?    boolean {carrierscarrier}?
      |   +--rw extranet-vpns {extranet-vpn}?
      |    +--rw extranet-vpn* [vpn-id]
      |      +--rw vpn-id       svc-id
      |      +--rw local-sites-role?  identityref
      +--rw sites
        +--rw site* [site-id]
         +--rw site-id         svc-id
         +--rw requested-site-start?  yang:date-and-time
         +--rw requested-site-stop?   yang:date-and-time
         +--rw locations
         | +--rw location* [location-id]
         |   +--rw location-id   svc-id
         |   +--rw address?    string
         |   +--rw postal-code?  string
         |   +--rw state?     string
         |   +--rw city?      string
         |   +--rw country-code?  string
         +--rw devices
         | +--rw device* [device-id]
         |   +--rw device-id   svc-id
         |   +--rw location?   leafref
         |   +--rw management
         |    +--rw address-family?  address-family
         |    +--rw address?     inet:ip-address
         +--rw site-diversity {site-diversity}?
         | +--rw groups
         |   +--rw group* [group-id]
         |    +--rw group-id  string
         +--rw management
         | +--rw type?  identityref
         +--rw vpn-policies
         | +--rw vpn-policy* [vpn-policy-id]
         |   +--rw vpn-policy-id  svc-id
         |   +--rw entries* [id]
         |    +--rw id    svc-id
         |    +--rw filter
         |    | +--rw (lan)?
         |    |   +--:(prefixes)
         |    |   | +--rw ipv4-lan-prefix*  inet:ipv4-prefix {ipv4}?
         |    |   | +--rw ipv6-lan-prefix*  inet:ipv6-prefix {ipv6}?
         |    |   +--:(lan-tag)
         |    |    +--rw lan-tag*      string
         |    +--rw vpn
         |      +--rw vpn-id    leafref
         |      +--rw site-role?  identityref
         +--rw site-vpn-flavor?     identityref
         +--rw maximum-routes
         | +--rw address-family* [af]
         |   +--rw af        address-family
         |   +--rw maximum-routes?  uint32
         +--rw security
         | +--rw authentication
         | +--rw encryption {encryption}?
         |   +--rw enabled?       boolean
         |   +--rw layer         enumeration
         |   +--rw encryption-profile
         |    +--rw (profile)?
         |      +--:(provider-profile)
         |      | +--rw profile-name?  string
         |      +--:(customer-profile)
         |       +--rw algorithm?    string
         |       +--rw (key-type)?
         |         +--:(psk)
         |         | +--rw preshared-key?  string
         |         +--:(pki)
         +--rw service
         | +--rw qos {qos}?
         | | +--rw qos-classification-policy
         | | | +--rw rule* [id]
         | | |   +--rw id          uint16
         | | |   +--rw (match-type)?
         | | |   | +--:(match-flow)
         | | |   | | +--rw match-flow
         | | |   | |   +--rw dscp?        inet:dscp
         | | |   | |   +--rw dot1p?        uint8
         | | |   | |   +--rw ipv4-src-prefix?   inet:ipv4-prefix
         | | |   | |   +--rw ipv6-src-prefix?   inet:ipv6-prefix
         | | |   | |   +--rw ipv4-dst-prefix?   inet:ipv4-prefix
         | | |   | |   +--rw ipv6-dst-prefix?   inet:ipv6-prefix
         | | |   | |   +--rw l4-src-port?     inet:port-number
         | | |   | |   +--rw target-sites*    svc-id
         | | |   | |   +--rw l4-src-port-range
         | | |   | |   | +--rw lower-port?  inet:port-number
         | | |   | |   | +--rw upper-port?  inet:port-number
         | | |   | |   +--rw l4-dst-port?     inet:port-number
         | | |   | |   +--rw l4-dst-port-range
         | | |   | |   | +--rw lower-port?  inet:port-number
         | | |   | |   | +--rw upper-port?  inet:port-number
         | | |   | |   +--rw protocol-field?   union
         | | |   | +--:(match-application)
         | | |   |   +--rw match-application?  identityref
         | | |   +--rw target-class-id?   string
         | | +--rw qos-profile
         | |   +--rw (qos-profile)?
         | |    +--:(standard)
         | |    | +--rw profile?  string
         | |    +--:(custom)
         | |      +--rw classes {qos-custom}?
         | |       +--rw class* [class-id]
         | |         +--rw class-id   string
         | |         +--rw rate-limit?  uint8
         | |         +--rw latency
         | |         | +--rw (flavor)?
         | |         |    ...
         | |         +--rw jitter
         | |         | +--rw (flavor)?
         | |         |    ...
         | |         +--rw bandwidth
         | |          +--rw guaranteed-bw-percent?  uint8
         | |          +--rw end-to-end?       empty
         | +--rw carrierscarrier {carrierscarrier}?
         | | +--rw signalling-type?  enumeration
         | +--rw multicast {multicast}?
         |   +--rw multicast-site-type?    enumeration
         |   +--rw multicast-address-family
         |   | +--rw ipv4?  boolean {ipv4}?
         |   | +--rw ipv6?  boolean {ipv6}?
         |   +--rw protocol-type?       enumeration
         +--rw traffic-protection {fast-reroute}?
         | +--rw enabled?  boolean
         +--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 sham-links {rtg-ospf-sham-link}?
         |   |   +--rw sham-link* [target-site]
         |   |    +--rw target-site  svc-id
         |   |    +--rw metric?    uint16
         |   +--rw bgp {rtg-bgp}?
         |   | +--rw autonomous-system?  uint32
         |   | +--rw address-family*   address-family
         |   +--rw static
         |   | +--rw cascaded-lan-prefixes
         |   |   +--rw ipv4-lan-prefixes* [lan next-hop] {ipv4}?
         |   |   | +--rw lan     inet:ipv4-prefix
         |   |   | +--rw lan-tag?  string
         |   |   | +--rw next-hop  inet:ipv4-address
         |   |   +--rw ipv6-lan-prefixes* [lan next-hop] {ipv6}?
         |   |    +--rw lan     inet:ipv6-prefix
         |   |    +--rw lan-tag?  string
         |   |    +--rw next-hop  inet:ipv6-address
         |   +--rw rip {rtg-rip}?
         |   | +--rw address-family*  address-family
         |   +--rw vrrp {rtg-vrrp}?
         |    +--rw address-family*  address-family
         +--ro actual-site-start?    yang:date-and-time
         +--ro actual-site-stop?    yang:date-and-time
         +--rw site-network-accesses
           +--rw site-network-access* [site-network-access-id]
            +--rw site-network-access-id   svc-id
            +--rw site-network-access-type?  identityref
            +--rw (location-flavor)
            | +--:(location)
            | | +--rw location-reference?     leafref
            | +--:(device)
            |   +--rw device-reference?      leafref
            +--rw access-diversity {site-diversity}?
            | +--rw groups
            | | +--rw group* [group-id]
            | |   +--rw group-id  string
            | +--rw constraints
            |   +--rw constraint* [constraint-type]
            |    +--rw constraint-type  identityref
            |    +--rw target
            |      +--rw (target-flavor)?
            |       +--:(id)
            |       | +--rw group* [group-id]
            |       |    ...
            |       +--:(all-accesses)
            |       | +--rw all-other-accesses?  empty
            |       +--:(all-groups)
            |         +--rw all-other-groups?   empty
            +--rw bearer
            | +--rw requested-type {requested-type}?
            | | +--rw requested-type?  string
            | | +--rw strict?      boolean
            | +--rw always-on?     boolean {always-on}?
            | +--rw bearer-reference?  string {bearer-reference}?
            +--rw ip-connection
            | +--rw ipv4 {ipv4}?
            | | +--rw address-allocation-type?   identityref
            | | +--rw number-of-dynamic-address?  uint8
            | | +--rw dhcp-relay
            | | | +--rw customer-dhcp-servers
            | | |   +--rw server-ip-address*  inet:ipv4-address
            | | +--rw addresses
            | |   +--rw provider-address?  inet:ipv4-address
            | |   +--rw customer-address?  inet:ipv4-address
            | |   +--rw mask?        uint8
            | +--rw ipv6 {ipv6}?
            | | +--rw address-allocation-type?   identityref
            | | +--rw number-of-dynamic-address?  uint8
            | | +--rw dhcp-relay
            | | | +--rw customer-dhcp-servers
            | | |   +--rw server-ip-address*  inet:ipv6-address
            | | +--rw addresses
            | |   +--rw provider-address?  inet:ipv6-address
            | |   +--rw customer-address?  inet:ipv6-address
            | |   +--rw mask?        uint8
            | +--rw oam
            |   +--rw bfd {bfd}?
            |    +--rw enabled?    boolean
            |    +--rw (holdtime)?
            |      +--:(profile)
            |      | +--rw profile-name?  string
            |      +--:(fixed)
            |       +--rw fixed-value?  uint32
            +--rw security
            | +--rw authentication
            | +--rw encryption {encryption}?
            |   +--rw enabled?       boolean
            |   +--rw layer         enumeration
            |   +--rw encryption-profile
            |    +--rw (profile)?
            |      +--:(provider-profile)
            |      | +--rw profile-name?  string
            |      +--:(customer-profile)
            |       +--rw algorithm?    string
            |       +--rw (key-type)?
            |         +--:(psk)
            |         |   ...
            |         +--:(pki)
            +--rw service
            | +--rw svc-input-bandwidth?  uint32
            | +--rw svc-output-bandwidth?  uint32
            | +--rw svc-mtu?        uint16
            | +--rw qos {qos}?
            | | +--rw qos-classification-policy
            | | | +--rw rule* [id]
            | | |   +--rw id          uint16
            | | |   +--rw (match-type)?
            | | |   | +--:(match-flow)
            | | |   | | +--rw match-flow
            | | |   | |    ...
            | | |   | +--:(match-application)
            | | |   |   +--rw match-application?  identityref
            | | |   +--rw target-class-id?   string
            | | +--rw qos-profile
            | |   +--rw (qos-profile)?
            | |    +--:(standard)
            | |    | +--rw profile?  string
            | |    +--:(custom)
            | |      +--rw classes {qos-custom}?
            | |       +--rw class* [class-id]
            | |          ...

            | +--rw carrierscarrier {carrierscarrier}?
            | | +--rw signalling-type?  enumeration
            | +--rw multicast {multicast}?
            |   +--rw multicast-site-type?    enumeration
            |   +--rw multicast-address-family
            |   | +--rw ipv4?  boolean {ipv4}?
            |   | +--rw ipv6?  boolean {ipv6}?
            |   +--rw protocol-type?       enumeration
            +--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 sham-links {rtg-ospf-sham-link}?
            |   |   +--rw sham-link* [target-site]
            |   |    +--rw target-site  svc-id
            |   |    +--rw metric?    uint16
            |   +--rw bgp {rtg-bgp}?
            |   | +--rw autonomous-system?  uint32
            |   | +--rw address-family*   address-family
            |   +--rw static
            |   | +--rw cascaded-lan-prefixes
            |   |   +--rw ipv4-lan-prefixes* [lan next-hop] {ipv4}?
            |   |   | +--rw lan     inet:ipv4-prefix
            |   |   | +--rw lan-tag?  string
            |   |   | +--rw next-hop  inet:ipv4-address
            |   |   +--rw ipv6-lan-prefixes* [lan next-hop] {ipv6}?
            |   |    +--rw lan     inet:ipv6-prefix
            |   |    +--rw lan-tag?  string
            |   |    +--rw next-hop  inet:ipv6-address
            |   +--rw rip {rtg-rip}?
            |   | +--rw address-family*  address-family
            |   +--rw vrrp {rtg-vrrp}?
            |    +--rw address-family*  address-family
            +--rw availability
            | +--rw access-priority?  uint32
            +--rw vpn-attachment
              +--rw (attachment-flavor)
               +--:(vpn-policy-id)
               | +--rw vpn-policy-id?  leafref
               +--:(vpn-id)
                 +--rw vpn-id?     leafref
                 +--rw site-role?    identityref

6.1.  Features and augmentation Augmentation

   The model defined in this document implements a lot of many features allowing that
   allow implementations to be modular.  As an example, an
   implementation may support only IPv4 VPNs
   (ipv4 (IPv4 feature), IPv6 (ipv6 VPNs
   (IPv6 feature), or both (by advertising both features).  The routing
   protocols proposed to the customer may also be enabled through
   features.  This model proposes also proposes some features for more advanced options like : extranet-vpn that
   are more advanced, such as support for extranet VPNs (Section 6.2.4),
   site diversity (Section 6.6), qos and QoS (Section 6.12.2),
   ... 6.12.2).

   In addition, as for any YANG model, this service model can be
   augmented to implement new behaviors or specific features.  For
   example, this model proposes different options for the IP address
   assignment,
   assignments; if those options are do not filling fulfill all requirements, new
   options can be added through augmentation.

6.2.  VPN service overview Service Overview

   A vpn-service list item contains generic informations information about the VPN
   service.  The vpn-id of "vpn-id" provided in the vpn-service list refers to an
   internal reference for this VPN service, while the customer name
   refers to a more
   explicit more-explicit reference to the customer.  This identifier
   is purely internal to the organization responsible for the VPN
   service.

6.2.1.  VPN service topology Service Topology

   The type of VPN service topology is required for configuration.
   Current proposal supports:  Our
   proposed model supports any-to-any, hub Hub and spoke Spoke (where hubs Hubs can
   exchange traffic), and hub "Hub and spoke disjoint Spoke disjoint" (where hubs Hubs cannot
   exchange traffic).  New topologies could be added by via augmentation.
   By default, the any-to-any VPN service topology is used.

6.2.1.1.  Route Target allocation Allocation

   A Layer 3 PE-based VPN is built using route-targets route targets (RTs) as
   described in [RFC4364].  It is expected the  The management system is expected to allocate
   automatically allocate a set of route-targets RTs upon receiving a VPN service
   creation request.  How the management system allocates route-targets RTs is out of
   scope of the document for this document, but multiple ways could be envisaged envisaged, as
   described below.

                                    Management system
                     <------------------------------------------------->
                                                 Request RT
                      +-----------------------+  Topo a2a   +----------+
           RESTCONF   |                       |  ----->     |          |
   User ------------- | Service Orchestration |             |NetworkOSS|             | Network  |
           l3vpn-svc  |                       |  <-----     |   OSS    |
             model
             Model    +-----------------------+   Response  +----------+
                                                  RT1,RT2
                                                  RT1, RT2

   In the example above, a service orchestration, owning the
   instantiation of this service model, request route-targets requests RTs to the network OSS.
   Based on the requested VPN service topology, the network OSS replies
   with one or multiple route-targets. RTs.  The interface between this service
   orchestration and the network OSS is out of scope of for this document.

                              +---------------------------+
                   RESTCONF   |                           |
           User ------------- |   Service Orchestration   |
                   l3vpn-svc  |                           |
            model
                     Model    |                           |
                              |  RT pool : pool: 10:1->10:10000  |
                              |  RT pool : pool: 20:50->20:5000  |
                              +---------------------------+

   In the example above, a service orchestration, owning the
   instantiation of this service model, owns one or more pools of route-
   target RTs
   (specified by service provider) the SP) that can be allocated.  Based on the requested
   VPN service topology, it will allocate one or multiple route-targets RTs from the
   pool.

   The mechanism displayed mechanisms shown above are just examples and should not be
   considered as an exhaustive list of solutions.

6.2.1.2.  Any to any  Any-to-Any

     +------------------------------------------------------------+
     |  VPN1_Site1 ------ PE1               PE2 ------ VPN1_Site2 |
     |                                                            |
     |  VPN1_Site3 ------ PE3               PE4 ------ VPN1_Site4 |
     +------------------------------------------------------------+

               Figure - Any-to-any

                     Any-to-Any VPN service topology Service Topology

   In the any-to-any VPN service topology, all VPN sites can communicate
   between
   with each other without any restriction.  It is expected that the restrictions.  The management system that
   receives an any-to-any IPVPN IP VPN service request through this model needs is
   expected to assign and then configure the VRF and
   route-targets RTs on the
   appropriate PEs.  In the any-to-any case, in
   general a single route-target RT is required generally
   required, and every VRF imports and exports this route-target. RT.

6.2.1.3.  Hub and Spoke

     +-------------------------------------------------------------+
     |   Hub_Site1 ------ PE1               PE2 ------ Spoke_Site1 |
     |                          +----------------------------------+
     |                          |
     |                          +----------------------------------+
     |   Hub_Site2 ------ PE3               PE4 ------ Spoke_Site2 |
     +-------------------------------------------------------------+

               Figure - Hub and Spoke

                     Hub-and-Spoke VPN service topology Service Topology

   In the hub and spoke Hub-and-Spoke VPN service topology, all spoke Spoke sites can
   communicate only with Hub sites but not between with each other, and hubs Hubs can
   also communicate between with each other.  It is expected that the  The management system that owns an any to any IPVPN
   any-to-any IP VPN service request through this model, needs model is expected to
   assign and then configure the VRF and
   route-targets RTs on the appropriate PEs.  In
   the hub and spoke Hub-and-Spoke case, in
   general a two route-targets RTs are generally required (one route-target RT for
   Hub
   routes, routes and one route-target RT for spoke Spoke routes).  A Hub VRF, connecting VRF that connects Hub sites,
   sites will export Hub routes with the Hub route-target, RT and will import Spoke
   routes through the Spoke route-target. RT.  It will also import the Hub route-target RT to allow Hub to Hub
   Hub-to-Hub communication.  A Spoke VRF,
   connecting VRF that connects Spoke sites, sites will
   export Spoke routes with the Spoke route-
   target, RT and will import Hub routes
   through the Hub route-target. RT.

   The management system MUST take into account Hub and constraints on Hub-and-
   Spoke
   connections constraints. connections.  For example, if a management system decides to
   mesh a spoke Spoke site and a hub Hub site on the same PE, it needs to mesh
   connections in different VRFs VRFs, as displayed shown in the figure below.

      Hub_Site ------- (VRF_Hub)  PE1
                                 (VRF_Spoke)
                                   /  |
   Spoke_Site1 -------------------+   |
                                      |
   Spoke_Site2 -----------------------+

6.2.1.4.  Hub and Spoke disjoint Disjoint

     +-------------------------------------------------------------+
     |   Hub_Site1 ------ PE1               PE2 ------ Spoke_Site1 |
     +--------------------------+  +-------------------------------+
                                |  |
     +--------------------------+  +-------------------------------+
     |   Hub_Site2 ------ PE3               PE4 ------ Spoke_Site2 |
     +-------------------------------------------------------------+

             Figure -

               Hub and Spoke disjoint Disjoint VPN service topology Service Topology

   In the Hub and Spoke disjoint VPN service topology, all Spoke sites
   can communicate only with Hub sites but not between with each other other, and Hubs
   cannot communicate between with each other.  It is expected that the  The management system that owns
   an any to any IPVPN any-to-any IP VPN service request through this model, needs model is expected
   to assign and then configure the VRF and
   route-targets RTs on the appropriate PEs.
   In the Hub and Spoke Hub-and-Spoke case, two
   route-targets RTs are required (one route-target RT for Hub routes,
   routes and one
   route-target RT for Spoke routes).  A Hub VRF, connecting VRF that connects Hub sites,
   sites will export Hub routes with the Hub route-target, RT and will import Spoke
   routes through the Spoke route-target. RT.  A Spoke VRF, connecting VRF that connects Spoke
   sites, sites
   will export Spoke routes with the Spoke route-target, RT and will import Hub routes
   through the Hub route-target. RT.

   The management system MUST take into account Hub and Spoke
   connections constraints on Hub-and-
   Spoke connections, as in the previous case.

   Hub and Spoke disjoint can also be seen as multiple Hub and Spoke Hub-and-Spoke
   VPNs (one per Hub) sharing with that share a common set of Spoke sites.

6.2.2.  Cloud access Access

   The proposed model provides a cloud access configuration through via the
   cloud-access
   "cloud-accesses" container.  The usage of cloud-access is targeted
   for the public cloud.  An Internet access can also be considered as a
   public cloud access service.  The cloud-access cloud-accesses container provides
   parameters for network address translations translation and authorization rules.

   A private cloud access may be addressed through NNIs NNIs, as described in
   Section 6.15.

   A cloud identifier is used to reference the target service.  This
   identifier is local to each administration.

   The model allows for source address translation before accessing the
   cloud.  IPv4 to IPv4  IPv4-to-IPv4 address translation (nat44) (NAT44) is the only
   supported option option, but other options can be added through
   augmentation.  If IP source address translation is required to access
   the cloud, the
   enabled "enabled" leaf MUST be set to true in the "nat44"
   container.  An IP address may be provided in the customer-address leaf, in case "customer-address"
   leaf if the customer is providing the IP address to be used for the
   cloud access.  If the service provider SP is providing this address, the customer-
   address
   "customer-address" is not necessary necessary, as it can be picked from a service provider
   pool. pool
   of SPs.

   By default, all sites in the IPVPN IP VPN MUST be authorized to access to the
   cloud.  In case  If restrictions are required, a user MAY configure the permit-site
   "permit-site" or deny-site "deny-site" leaf-list.  The "permit-site" permit-site leaf-list
   defines the list of sites authorized for cloud access.  The "deny-site" deny-site
   leaf-list defines the list of sites denied for cloud access.  The
   model supports both "deny any except" "deny-any-except" and "permit any except" "permit-any-except"
   authorization.

   How the restrictions will be configured on network elements is out of
   scope of for this document.

                     IPVPN

                     IP VPN
           ++++++++++++++++++++++++++++++++     +++++++++++     ++++++++++++
           +             Site 3           + --- +  Cloud1  Cloud 1 +
           + Site 1                       +     +++++++++++     ++++++++++++
           +                              +
           + Site 2                       + --- ++++++++++++
           +                              +     + Internet +
           +            Site 4            +     ++++++++++++
           ++++++++++++++++++++++++++++++++
                        |
                ++++++++++
                   +++++++++++
                   + Cloud2 Cloud 2 +
                ++++++++++
                   +++++++++++

   In the example above, we may configure the global VPN to access the
   Internet by creating a cloud-access pointing to the cloud identifier
   for the Internet service.  No authorized-sites authorized sites will be configured configured, as
   all sites are required to access the Internet.  The "address-
   translation/nat44/enabled"
   "address-translation/nat44/enabled" leaf will be set to true.

   <vpn-service>
       <vpn-id>123456487</vpn-id>
       <cloud-accesses>
        <cloud-access>
           <cloud-identifier>INTERNET</cloud-identifier>
           <address-translation>
             <nat44>
               <enabled>true</enabled>
             </nat44>
           </address-translation>
        </cloud-access>
       </cloud-accesses>
   </vpn-service>
   If Site1 Site 1 and Site2 requires Site 2 require access to Cloud1, Cloud 1, a new cloud-access will
   be created
   pointing to the cloud identifier of Cloud1. Cloud 1 will be created.  The "permit-
   site"
   permit-site leaf-list will be filled with a reference to Site1 Site 1 and Site2.
   Site 2.

   <vpn-service>
       <vpn-id>123456487</vpn-id>
       <cloud-accesses>
        <cloud-access>
           <cloud-identifier>Cloud1</cloud-identifier>
           <permit-site>site1</permit-site>
           <permit-site>site2</permit-site>
        <cloud-access>
        </cloud-access>
       </cloud-accesses>
   </vpn-service>

   If all sites except Site1 requires Site 1 require access to Cloud2, Cloud 2, a new cloud-
   access will be created
   cloud-access pointing to the cloud identifier of Cloud2. Cloud 2 will be
   created.  The "deny-site" deny-site leaf-list will be filled with a reference to Site1.
   Site 1.

   <vpn-service>
       <vpn-id>123456487</vpn-id>
       <cloud-accesses>
        <cloud-access>
           <cloud-identifier>Cloud2</cloud-identifier>
           <deny-site>site1</deny-site>
        </cloud-access>
       </cloud-accesses>
   </vpn-service>

6.2.3.  Multicast service Service

   Multicast in IP VPN VPNs is described in [RFC6513].

   If multicast support is required for an IPVPN, IP VPN, some global multicast
   parameters are required as input of for the service request.

   The user

   Users of this model will need to fill provide the flavor flavors of trees that
   will be used by customer customers within the IPVPN (Customer IP VPN (customer tree).  The
   proposed model supports bidirectional, shared shared, and source-based trees
   (and can be augmented).  Multiple flavors of tree trees can be supported
   simultaneously.

                                   Operator network
                                   ______________
                                  /               \
                                 |                 |
                          (SSM tree)               |
    Recv (IGMPv3) -- Site2 ------- PE2             |
                                 |             PE1 --- Site1 --- Source1
                                 |                 |        \
                                 |                 |         -- Source2
                                 |                 |
                           (ASM tree)              |
    Recv (IGMPv2) -- Site3 ------- PE3             |
                                 |                 |
                           (SSM tree)              |
    Recv (IGMPv3) -- Site4 ------- PE4             |
                                 | /               |
    Recv (IGMPv2) -- Site5 --------                |
                           (ASM tree)              |
                                 |                 |
                                  \_______________/

   In case of

   When an ASM flavor is requested, this model requires to fill that the
   rp "rp"
   and rp-discovery parameters. "rp-discovery" parameters be filled.  Multiple RP to group RP-to-group
   mappings can be created using the rp-group-mappings "rp-group-mappings" container.  For
   each mapping, the
   RP service SP can be managed by manage the RP service provider using by setting the leaf
   "provider-managed/enabled" set leaf to true.  In the case of provider a provider-
   managed RP, the user can request a rendez-vous point RP redundancy and/or an optimal traffic
   delivery.  Those parameters will help the service
   provider to SP select the appropriate
   technology or architecture to fulfill the customer service
   requirement: for instance, in the case of a request for an optimal
   traffic delivery, a service provider an SP may use Anycast-RP or RP-tree to SPT RP-tree-to-SPT
   switchover architectures.

   In the case of a customer managed customer-managed RP, the RP address must be filled
   in the RP to group RP-to-group mappings using the "rp-address" leaf.  This leaf
   is not needed for a provider managed provider-managed RP.

   User

   Users can define a specific rp-discovery mechanism like: auto-rp,
   static-rp, bsr-rp for RP discovery, such as the
   "auto-rp", "static-rp", or "bsr-rp" modes.  By default, the model considers static-rp
   uses "static-rp" if ASM is requested.  A single rp-discovery
   mechanism is allowed for the VPN.  The "rp-discovery" container can
   be used for both provider provider-managed and customer managed customer-managed RPs.  In the
   case of a provider managed provider-managed RP, if the user wants to use bsr-rp "bsr-rp" as a
   discovery protocol, a service provider an SP should consider the provider managed rp-group-mappings provider-managed
   "rp-group-mappings" for the bsr-rp "bsr-rp" configuration.  The service provider SP will then
   configure its selected RPs to be bsr-rp-candidates. "bsr-rp-candidates".  In the case of
   a customer managed customer-managed RP and a
   bsr-rp "bsr-rp" discovery mechanism, the rp-address
   "rp-address" provided will be
   considered as the bsr-rp candidate.

6.2.4.  Extranet VPNs

   There are some cases where a particular VPN needs to access to resources
   (servers, hosts ...) hosts, etc.) that are external.  These  Those resources may be
   located in another VPN.

                 +-----------+           +-----------+
                /             \         /             \
   SiteA
     Site A -- |    VPN A      |  ---  |    VPN B      | --- SiteB Site B
                \             /         \             / (Shared
                 +-----------+           +-----------+   resources)

   In the figure above, VPN B has some resources on Site B that need to
   be available to some customers/partners.  VPN A must be able to
   access those VPN B resources.

   Such a VPN connection scenario can be achieved by the via a VPN policy as
   defined in Section 6.5.2.2.  But there are some simple cases where a
   particular VPN (VPN A) needs to access to all resources in a another VPN B.
   (VPN B).  The model provides an easy way to setup set up this connection
   using the "extranet-vpns" container.

   The "extranet-vpns" extranet-vpns container defines a list of VPNs a particular VPN
   wants to access.  The "extranet-vpns" extranet-vpns container must be used on
   customer VPNs accessing extranet resources in another VPN.  In the
   figure above, in order to give access for provide VPN A with access to VPN B, the
   extranet-vpns container needs to be configured under VPN A with an
   entry corresponding to VPN
   B and there B.  There is no service configuration
   requirement on VPN B.

   Readers should note that even if there is no configuration
   requirement on VPN B, if VPN A lists VPN B as an extranet, all sites
   in VPN B will gain access to all sites in VPN A.

   The "site-role" leaf defines the role of the local VPN sites in the
   target extranet VPN service topology.  Site roles are defined in
   Section 6.4.  Based on this, the requirements described in
   Section 6.4 regarding the site-role leaf are also applicable here.

   In the example below, VPN A accesses to VPN B resources through an
   extranet connection, a connection.  A Spoke role is required for VPN A sites sites, as
   sites from VPN A must not be able to communicate between with each other
   through the extranet VPN connection.

   <vpn-service>
       <vpn-id>VPNB</vpn-id>
       <vpn-service-topology>hub-Spoke</vpn-service-topology>
       <vpn-service-topology>hub-spoke</vpn-service-topology>
   </vpn-service>
   <vpn-service>
       <vpn-id>VPNA</vpn-id>
       <vpn-service-topology>any-to-any</vpn-service-topology>
       <extranet-vpns>
           <extranet-vpn>
               <vpn-id>VPNB</vpn-id>
               <site-role>spoke-role</site-role>
           </extranet-vpn>
       </extranet-vpns>
   </vpn-service>

   This model does not define how the extranet configuration will be
   achieved.

   Any more complex VPN interconnection scenario (e.g. that is more complex (e.g., only part
   certain parts of sites of on VPN A accessing only part certain parts of sites of
   on VPN B) needs to be achieved using the vpn a VPN attachment as defined in
   Section 6.5.2 6.5.2, and especially the a VPN policy as defined in
   Section 6.5.2.2.

6.3.  Site overview Overview

   A site represents a connection of a customer office to one or more
   VPN services.

                                                    +-------------+
                                                   /               \
     +------------------+                   +-----|      VPN1       |
     |                  |                   |      \               /
     |  New York Office | ----- |------ (site) -----+       +-------------+
     |                  |                   |       +-------------+
     +------------------+                   |      /               \
                                            +-----|      VPN2       |
                                                   \               /
                                                    +-------------+
   A site is composed of some characteristics : has several characteristics:

   o  Unique identifier (site-id): to uniquely identify identifies the site within
      the overall network infrastructure.  The identifier is a string
      allowing to
      that allows any encoding for the local administration of the VPN
      service.

   o  Locations (locations): site location information to allow that allows easy
      retrieval on of information from the nearest available resources.  A
      site may be composed of multiple locations.

   o  Devices:  Devices (devices): allows the customer can to request one or more
      customer premise
      equipments premises equipment entities from the service provider SP for a particular
      site.

   o  Management (management): defines the model type of management of for the
      site,
      site -- for example : example, co-managed, customer managed customer-managed, or provider provider-
      managed.  See Section 6.10.

   o  Site network accesses (site-network-accesses): defines the list of
      network accesses associated to with the sites sites, and their properties :
      -- especially bearer, connection connection, and service parameters.

   A site-network-access represents an IP logical connection of a site.
   A site may have multiple site-network-accesses.

     +------------------+             Site
     |                  |-----------------------------------
     |                  |****** (site-network-access#1) ******
     |  New York Office |
     |                  |****** (site-network-access#2) ******
     |                  |-----------------------------------
     +------------------+

   Multiple site-network-accesses are used used, for instance instance, in the case of
   multihoming.  Some other meshing cases may also involve include multiple
   site-network-accesses.

   The site configuration is viewed as a global entity, entity; we assume that
   it is mostly the role of the management system's role to split the parameters
   between the different elements within the network.  For example, in
   the case of the site-network-access configuration, the management
   system needs to split the overall parameters between the PE
   configuration and the CE configuration.

6.3.1.  Devices and locations Locations

   A site may be composed of multiple locations.  All the locations will
   need to be configured as part of the "locations" container and list.
   A typical example of multilocation a multi-location site is an headquarter a headquarters office
   in a city composed of multiple buildings.  Those buildings may be
   located in different parts of the city and may be linked by
   intra-city fibers (customer metropolitan area network).  In such a
   case, when connecting to a VPN service, the customer may ask for
   multihoming based on its distributed locations.

       New York Site

     +------------------+             Site
     | +--------------+ |-----------------------------------
     | | Manhattan    | |****** (site-network-access#1) ******
     | +--------------+ |
     | +--------------+ |
     | | Brooklyn     | |****** (site-network-access#2) ******
     | +--------------+ |
     |                  |-----------------------------------
     +------------------+

   A customer may also request some premise equipments premises equipment entities (CEs) to
   from the
   service provider through SP via the "devices" container.  Requesting a CE implies a
   provider-managed or co-managed model.  A particular device must be
   ordered to a particular already configured already-configured location.  This would help
   the service provider to SP send the device to the appropriate postal address.  In a multilocation
   multi-location site, a customer may may, for example example, request a CE for
   each location on the site where multihoming must be implemented.  In
   the figure above, one device may be requested for the Manhattan
   location and one other for the Brooklyn location.

   By using devices and locations, the user can influence the
   multihoming scenario he wants to implement: single CE, dual CE... CE, etc.

6.3.2.  Site network accesses Network Accesses

   As mentioned, mentioned earlier, a site may be multihomed.  Each IP network
   access for a site is defined in the site-network-accesses list. "site-network-accesses"
   container.  The site-network-
   access site-network-access parameter defines how the site is
   connected on the network and is split into three main classes of
   parameters:

   o  bearer: defines requirements of the attachment (below Layer 3).

   o  connection: defines Layer 3 protocol parameters of the attachment.

   o  availability: defines the site site's availability policy.  The
      availability parameters are defined in Section 6.7 6.7.

   The site-network-access has a specific type (site-network-access-
   type).
   (site-network-access-type).  This documents document defines two types : types:

   o  point-to-point: describes a point to point point-to-point connection between the
      service provider
      SP and the customer.

   o  multipoint: describes a multipoint connection between the service
      provider SP and
      the customer.

   The type of site-network-access may have an impact on the parameters
   offered to the customer, e.g., a service provider an SP may not offer encryption for
   multipoint accesses.  Deciding  It is up to the provider to decide what
   parameter is supported for point-to-point and/or multipoint accesses is up to the
   provider and accesses;
   this topic is out of scope of for this document.  Some containers
   proposed in the model may require extension extensions in order to work
   properly for multipoint accesses.

6.3.2.1.  Bearer

   The "bearer" bearer container defines the requirements for the site attachment
   to the provider network that are below Layer 3.

   The bearer parameters will help to determine the access media to be
   used.  This is further described in Section 6.6.3.

6.3.2.2.  Connection

   The "ip-connection" container defines the protocol parameters of the
   attachment (IPv4 and IPv6).  Depending on the management mode, it
   refers to the PE-CE addressing or CE to customer LAN CE-to-customer-LAN addressing.  In any
   case, it describes the provider to customer responsibility
   boundary. boundary between the provider
   and the customer.  For a customer managed customer-managed site, it refers to the
   PE-CE connection.  For a provider managed provider-managed site, it refers to the CE to LAN
   CE-to-LAN connection.

6.3.2.2.1.  IP addressing Addressing

   An IP subnet can be configured for either layer IPv4 or IPv6 Layer 3
   protocols.  For a
   dual stack dual-stack connection, two subnets will be
   provided, one for each address family.

   The address-allocation-type "address-allocation-type" determines how the address allocation
   needs to be done.  The current model proposes five ways of to perform IP
   address allocation:

   o  provider-dhcp: the The provider will provide DHCP service for customer
      equipments,
      equipment; this is can be applied applicable to either IPv4 and IPv6
      containers. the "IPv4" container or
      the "IPv6" container.

   o  provider-dhcp-relay: the The provider will provide DHCP relay service
      for customer equipments, equipment; this is applicable to both IPv4 and IPv6
      addressing.  The customer needs to fill populate the DHCP server list
      to be used.

   o  static-address: Addresses will be assigned manually, manually; this is
      applicable to both IPv4 and IPv6 addressing.

   o  slaac: This parameter enables stateless address autoconfiguration ([RFC4862]).
      [RFC4862].  This is applicable only for IPv6. to IPv6 only.

   o  provider-dhcp-slaac: the The provider will provide DHCP service for
      customer equipments equipment, as well as stateless address
      autoconfiguration.  This is applicable only for IPv6. to IPv6 only.

   In the dynamic addressing mechanism, it the SP is expected from the service
   provider to provide at
   least the IP address, mask mask, and default gateway information.

6.3.2.2.2.  OAM

   A customer may require a specific IP connectivity fault detection
   mechanism on the IP connection.  The model supports BFD as a fault
   detection mechanism.  This can be extended with other mechanisms by via
   augmentation.  The provider can propose some profiles to the customer
   customer, depending of on the service level the customer wants to
   achieve.  Profile names must be communicated to the customer.  This
   communication is out of scope of for this document.  Some fixed values
   for the holdtime period may also be imposed by the customer if the
   provider enables it. allows the customer this function.

   The OAM "oam" container can easily be augmented by other mechanisms,
   especially mechanisms; in
   particular, work from done by the LIME Working Group
   (https://datatracker.ietf.org/wg/lime/charter/) may be reused. reused in
   applicable scenarios.

6.3.2.3.  Inheritance of parameters between site Parameters Defined at Site Level and site-network-access Site
          Network Access Level

   Some parameters can be configured both at both the site level at and the site-
   network-access level: e.g.
   site-network-access level, e.g., routing, services, security... security.
   Inheritance applies when parameters are defined at the site level.
   If a parameter is configured at both the site level and the access
   level, the access level access-level parameter MUST override the site level site-level
   parameter.  Those parameters will be described later in the this
   document.

   In terms of provisionning provisioning impact, it will be up to the implementation
   to decide of on the appropriate behavior when modifying existing
   configurations.  But the service provider SP will need to communicate to the user
   about the impact of using inheritance.  For example, if we consider
   that a site has already provisionned provisioned three site-network-
   accesses, site-network-accesses, what
   will happen if a customer is changing changes a service parameter at the site level ?
   level?  An implementation of this model may update the service
   parameters of all already provisionned site-network-
   accesses already-provisioned site-network-accesses (with
   potential impact on live traffic) traffic), or it may take into account this
   new parameter only for the new sites.

6.4.  Site role Role

   A VPN has a particular service topology topology, as described in
   Section 6.2.1.  As a consequence, each site belonging to a VPN is
   assigned with a particular role in this topology.  The site-role leaf
   defines the role of the site in a particular VPN topology.

   In the any-to-any VPN service topology, all sites MUST have the same
   role
   role, which is any-to-any-role. will be "any-to-any-role".

   In the hub-spoke Hub-and-Spoke VPN service topology or hub-spoke-disjoint the Hub and Spoke
   disjoint VPN service topology, sites MUST have a hub-role Hub role or a spoke-role.
   Spoke role.

6.5.  Site belonging Belonging to multiple Multiple VPNs

6.5.1.  Site vpn flavor VPN Flavor

   A site may be part of one or multiple VPNs.  The site flavor "site-vpn-flavor"
   defines the way the VPN multiplexing is done.  The current version of
   the model supports four flavors:

   o  site-vpn-flavor-single: the The site belongs to only one VPN.

   o  site-vpn-flavor-multi: the The site belongs to multiple VPNs VPNs, and all
      the logical accesses of the sites belongs belong to the same set of VPNs.

   o  site-vpn-flavor-sub: the The site belongs to multiple VPNs with
      multiple logical accesses.  Each logical access may map to
      different VPNs (one or many).

   o  site-vpn-flavor-nni: the The site represents an option A NNI.

6.5.1.1.  Single VPN attachment : Attachment: site-vpn-flavor-single

   The figure below describes the a single VPN attachment.  The site
   connects to only one VPN.

                                                      +--------+
   +------------------+             Site             /          \
   |                  |-----------------------------|            |
   |                  |***(site-network-access#1)***|    VPN1    |
   |  New York Office |                             |            |
   |                  |***(site-network-access#2)***|            |
   |                  |-----------------------------|            |
   +------------------+                              \          /
                                                      +--------+

6.5.1.2.  Multi VPN attachment :  MultiVPN Attachment: site-vpn-flavor-multi

   The figure below describes a site connected to multiple VPNs.

                                                           +---------+
                                                      +---/----+      \
   +------------------+             Site             /   |      \      |
   |                  |--------------------------------- |       |VPN B|
   |                  |***(site-network-access#1)******* |       |     |
   |  New York Office |                             |    |       |     |
   |                  |***(site-network-access#2)*******  \      |    /
   |                  |-----------------------------| VPN A+-----|---+
   +------------------+                              \          /
                                                      +--------+
   In the example above, the New York office is multihomed, both multihomed.  Both
   logical accesses are using the same VPN attachment rules.  Both logical
   accesses rules, and both
   are connected to VPN A and VPN B.

   Reaching VPN A or VPN B from the New York office will be based on
   destination based done via
   destination-based routing.  Having the same destination reachable
   from the two VPNs may cause routing troubles.  This  The customer
   administration's role in this case would be the role
   of the customer administration to ensure the appropriate
   mapping of its prefixes in each VPN.

6.5.1.3.  Sub VPN attachment :  SubVPN Attachment: site-vpn-flavor-sub

   The figure below describes a subVPN attachment.  The site connects to
   multiple VPNs VPNs, but each logical access is attached to a particular
   set of VPN. VPNs.  A typical use case of for a subVPN is a customer site used
   by multiple affiliates with private resources for each affiliates affiliate that
   cannot be shared (communication is prevented between the affiliates). affiliates is prevented).
   It is similar than to having separate sites instead that sites, but in this case the customer
   wants to share some physical components while keeping a maintaining strong
   communication isolation between the affiliates.  In the this example, the
   access#1
   site-network-access#1 is attached to VPN B B, while the access#2
   site-network-access#2 is attached to VPNA. VPN A.

   +------------------+         Site                      +--------+
   |                  |----------------------------------/          \
   |                  |****(site-network-access#1)******|    VPN B   |
   |  New York Office |                                  \          /
   |                  |                                   +--------+
   |                  |                                   +--------+
   |                  |                                  /          \
   |                  |****(site-network-access#2)******|    VPN A   |
   |                  |                                  \          /
   |                  |                                   +--------+
   |                  |-----------------------------------
   +------------------+

   MultiVPN
   A multiVPN can be implemented in addition to subVPN, a subVPN; as a
   consequence, each site-network-access can access to multiple VPNs.  In
   the example below, access#1 site-network-access#1 is mapped to VPN B and
   VPN C, while access#2 site-network-access#2 is mapped to VPN A and VPN D.

  +------------------+

   +-----------------+         Site                      +-----+                    +------+
   |                  |----------------------------------/      +----+                 |--------------------------------/       +-----+
   |                  |****(site-network-access#1)******|                 |****(site-network-access#1)****| VPN B/ B /       \
   | New York Office |                                \     |  VPN C  |
   |                 |                                   +----\                                 +-----\       /
   |                 |                                        +-----+
   |                 |
   |                 |                                   +------+                                 +-------+
   |                 |                                /        +-----+
   |                  |****(site-network-access#2)******|                 |****(site-network-access#2)****| VPN A/ A  /       \
   |                 |                                \      | VPN D   |
   |                 |                                 +------\       /
   |                  |-----------------------------------        +---+
  +------------------+                 |---------------------------------        +-----+
   +-----------------+

   Multihoming is also possible with subVPN, subVPNs; in this case, site-network-
   accesses
   site-network-accesses are grouped, and a particular group will have
   access to the same set of VPNs.  In the example below, access#1
   site-network-access#1 and #2 site-network-access#2 are part of the same
   group (multihomed together) and are mapped to VPN B and C, VPN C; in
   addition access#3
   addition, site-network-access#3 and #4 site-network-access#4 are part of
   the same group (multihomed together) and are mapped to VPN A and
   VPN D.

  +------------------+

   +-----------------+         Site                      +-----+                     +------+
   |                  |----------------------------------/      +----+                 |---------------------------------/       +-----+
   |                  |****(site-network-access#1)******| VPNB                 |****(site-network-access#1)*****| VPN B /       \
   | New York Office |****(site-network-access#2)******\ |****(site-network-access#2)***** \     |  VPN C  |
   |                 |                                   +----\                                  +-----\       /
   |                 |                                         +-----+
   |                 |
   |                 |                                  +------+
   |                 |                                 /       +-----+
   |                  |****(site-network-access#3)******|  VPNA                 |****(site-network-access#3)*****| VPN A /       \
   |                  |****(site-network-access#4)******                 |****(site-network-access#4)***** \     | VPN D   |
   |                 |                                   +------\                                  +-----\       /
   |                  |-----------------------------------        +---+
  +------------------+                 |----------------------------------       +-----+
   +-----------------+

   In terms of service configuration, a subVPN can be achieved by
   requesting that the site-network-access to use the same bearer (see
   Section
   Sections 6.6.4 and Section 6.6.6.4 for more details).

6.5.1.4.  NNI :  NNI: site-vpn-flavor-nni

   Some Network to Network

   A Network-to-Network Interface (NNI) scenario may be modeled using
   the site sites container (see Section 6.15.1).  Using the site sites container
   to model an NNI is only one possible option for NNI NNIs (see
   Section 6.15).  This option is called option A "option A" by reference to the
   option A NNI defined in [RFC4364].  It is helpful for the service provider SP to
   identify
   indicate that the requested VPN connection is not a regular site but
   a NNI
   rather is an NNI, as specific default device configuration parameters
   may be applied in the case of NNI (e.g. NNIs (e.g., ACLs, routing policies...). policies).

          SP A                                             SP B
    ---------------------                         --------------------
     -------------------                         -------------------
    /                   \                       /                   \
   |                     |                     |                     |
   |                 ++++++++ InterAS Inter-AS link ++++++++                 |
   |                 +      +_____________ +      +_______________+      +                 |
   |                 +  (VRF1)--(VPN1)----(VRF1)  (VRF1)---(VPN1)----(VRF1)  +                 |
   |                 + ASBR +               + ASBR +                 |
   |                 +  (VRF2)--(VPN2)----(VRF2)  (VRF2)---(VPN2)----(VRF2)  +                 |
   |                 +      +______________+      +_______________+      +                 |
   |                 ++++++++               ++++++++                 |
   |                     |                     |                     |
   |                     |                     |                     |
   |                     |                     |                     |
   |                 ++++++++ InterAS Inter-AS link ++++++++                 |
   |                 +      +_____________ +      +_______________+      +                 |
   |                 +  (VRF1)--(VPN1)----(VRF1)  (VRF1)---(VPN1)----(VRF1)  +                 |
   |                 + ASBR +               + ASBR +                 |
   |                 +  (VRF2)--(VPN2)----(VRF2)  (VRF2)---(VPN2)----(VRF2)  +                 |
   |                 +      +______________+      +_______________+      +                 |
   |                 ++++++++               ++++++++                 |
   |                     |                     |                     |
   |                     |                     |                     |
    \                   /                       \                   /
     --------------------
     -------------------                         -------------------

   The figure above describes an option A NNI scenario that can be
   modeled using the site sites container.  In order to connect its customer
   VPN
   VPNs (VPN1 and VPN2) on the in SP B network, B, SP A may request the creation of some
   site-network-accesses to SP B.  The site-vpn-flavor-
   nni site-vpn-flavor-nni will be used
   to inform SP B that this is an NNI and not a regular customer site.
   The site-vpn-flavor-nni may be multihomed and multiVPN as well.

6.5.2.  Attaching a site Site to a VPN

   Due to the multiple site-vpn flavors, the attachment of a site to an
   IPVPN
   IP VPN is done at the site-network-access (logical access) level
   through the vpn-attachment "vpn-attachment" container.  The vpn-attachment container
   is mandatory.  The model provides two ways of attachment: to attach a site to a VPN:

   o  By referencing directly the target VPN. VPN directly.

   o  By referencing a VPN policy for attachments that are more complex attachments. complex.

   A choice is implemented to allow the user to choose the flavor that
   provides the best fitting
   flavor. fit.

6.5.2.1.  Reference  Referencing a VPN

   Referencing a vpn-id provides an easy way to attach a particular
   logical access to a VPN.  This is the best way in the case of a
   single VPN attachment or subVPN with a single VPN attachment per
   logical access.  When referencing a vpn-id, the site-role setting
   must be added to express the role of the site in the target VPN
   service topology.

   <site>
    <site-id>SITE1</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>LA1</site-network-access-id>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
     <site-network-access>
      <site-network-access-id>LA2</site-network-access-id>
      <vpn-attachment>
       <vpn-id>VPNB</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>

   The example above describes a subVPN case where a site SITE1 (SITE1) has
   two logical accesses (LA1 and LA2) LA2), with LA1 attached to VPNA and LA2
   attached to VPNB.

6.5.2.2.  VPN policy Policy

   The vpn-policy "vpn-policy" list helps to express a multiVPN scenario where a
   logical access belongs to multiple VPNs.  Multiple VPN policies can
   be created to handle the subVPN case where each logical access is
   part of a different set of VPNs.

   As a site can belong to multiple VPNs, the vpn-policy list may be
   composed of multiple entries.  A filter can be applied to specify
   that only some LANs of the site should be part of a particular VPN.
   Each time a site (or LAN) is attached to a VPN, the user must
   precisely describe its role (site-role) within the target VPN service
   topology.

   +--------------------------------------------------------------+
   |       Site1 ------ PE7                                       |
   +-------------------------+                 [VPN2]             |
                             |                                    |
   +-------------------------+                                    |
   |       Site2 ------ PE3               PE4 ------ Site3        |
   +----------------------------------+                           |
                                      |                           |
   +------------------------------------------------------------+ |
   |       Site4 ------ PE5           |   PE6 ------ Site5      | |
   |                                                            | |
   |                      [VPN3]                                | |
   +------------------------------------------------------------+ |
                                      |                           |
                                      +---------------------------+

   In the example above, Site5 is part of two VPNs: VPN3 and VPN2.  It
   will play a hub-role Hub role in VPN2 and an any-to-any role in VPN3.  We can
   express such a multiVPN scenario as follows:

   <site>
    <site-id>Site5</site-id>
    <vpn-policies>
     <vpn-policy>
      <vpn-policy-id>POLICY1</vpn-policy-id>
      <entries>
       <id>ENTRY1</id>
       <vpn>
        <vpn-id>VPN2</vpn-id>
        <site-role>hub-role</site-role>
       </vpn>
      </entries>
      <entries>
       <id>ENTRY2</id>
       <vpn>
        <vpn-id>VPN3</vpn-id>
        <site-role>any-to-any-role</site-role>
       </vpn>
      </entries>
     </vpn-policy>
    </vpn-policies>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>LA1</site-network-access-id>
      <vpn-attachment>
       <vpn-policy-id>POLICY1</vpn-policy-id>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>

   Now, if a more granular more-granular VPN attachment is necessary, filtering can be
   used.  For example, if LAN1 from Site5 must be attached to VPN2 as a
   Hub and LAN2 must be attached to VPN3, the following configuration
   can be used:

   <site>
    <site-id>Site5</site-id>
    <vpn-policies>
     <vpn-policy>
      <vpn-policy-id>POLICY1</vpn-policy-id>
      <entries>
       <id>ENTRY1</id>
       <filter>
        <lan-tag>LAN1</lan-tag>
       </filter>
       <vpn>
        <vpn-id>VPN2</vpn-id>
        <site-role>hub-role</site-role>
       </vpn>
      </entries>
      <entries>
       <id>ENTRY2</id>
       <filter>
        <lan-tag>LAN2</lan-tag>
       </filter>
       <vpn>
        <vpn-id>VPN3</vpn-id>
        <site-role>any-to-any-role</site-role>
       </vpn>
      </entries>
     </vpn-policy>
    </vpn-policies>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>LA1</site-network-access-id>
      <vpn-attachment>
       <vpn-policy-id>POLICY1</vpn-policy-id>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>

6.6.  Deciding where Where to connect Connect the site Site

   The management system will have to determine where to connect each
   site-network-access of a particular site to the provider network (PE,
   (e.g., PE, aggregation switch ...). switch).

   The current model proposes parameters and constraints that can
   influence the meshing of the site-network-access.

   The management system SHOULD honor the any customer constraints, if the constraints.  If a
   constraint is too strict and can not cannot be filled, fulfilled, the management
   system MUST not NOT provision the site and SHOULD provide an relevant
   information to the user.  How the information is provided is out of
   scope of the for this document.  It  Whether or not to relax the constraint
   would then be left up to the user to relax the constraint or
   not. user.

   Parameters are just hints for the management system for service
   placement.

   In addition to parameters and constraints, the management system system's
   decision MAY be based on any other internal constraint constraints that are left
   up to the service provider: SP: least load, distance ... distance, etc.

6.6.1.  Constraint: Device

   In the case of provider-management provider management or co-management, one or more
   devices have been ordered by the customer.  The customer may force a
   particular site-network-access to be connected on a particular device
   that he ordered.

       New York Site

     +------------------+             Site
     | +--------------+ |-----------------------------------
     | | Manhattan    | |
     | |           CE1********* (site-network-access#1) ******
     | +--------------+ |
     | +--------------+ |
     | | Brooklyn  CE2********* (site-network-access#2) ******
     | +--------------+ |
     |                  |-----------------------------------
     +------------------+

   In the figure above, the site-network-access#1 is associated to with CE1 in
   the service request.  The service provider SP must ensure the
   provisionning provisioning of this
   connection.

6.6.2.  Constraint/parameter:  Constraint/Parameter: Site location Location

   The location information provided in this model MAY be used by a
   management system to determine the target PE to mesh the site
   (service provider
   (SP side).  A particular location must be associated to with each site
   network access when configuring it.  The service provider SP MUST honor the
   termination of the access on the location associated with the site
   network access (customer side).  The country-code "country-code" in the site-location
   site location SHOULD be expressed as an ISO ALPHA-2 code.

   The site-network-access location is determined by the "location-
   flavor".
   "location-flavor".  In the case of a provider-managed or co-managed
   site, the user is expected to configure a "device-reference" (device
   case) that will bind the site-network-access to a particular device
   that the customer ordered.  As each device is already associated to with
   a particular location, in such a case the location information is
   retrieved from the device location.  In the case of customer-managed a customer-
   managed site, the user is expected to configure a
   "location-reference" (location case), case); this provides a reference to an
   existing configured location and will help
   the with placement.

                                        PoP#1

                                         POP#1 (New York)
                                      +---------+
                                      |   PE1   |
                 Site #1 ---...       |   PE2   |
                (Atlantic City)       |   PE3   |
                                      +---------+

                                        PoP#2

                                         POP#2 (Washington)
                                      +---------+
                                      |   PE4   |
                                      |   PE5   |
                                      |   PE6   |
                                      +---------+

                                        PoP#3

                                         POP#3 (Philadelphia)
                                      +---------+
                                      |   PE7   |
                 Site #2 CE#1---...   |   PE2   PE8   |
                (Reston)              |   PE9   |
                                      +---------+

   In the example above, Site#1 Site #1 is a customer managed customer-managed site with a
   location L1, while Site#2 Site #2 is a provider-managed site for which a CE#1 CE
   (CE#1) was ordered, Site#2 ordered.  Site #2 is configured with L2 as its location.
   When configuring a site-network-access for Site#1, Site #1, the user will
   need to reference the location L1, L1 so that the management system will know
   that the access will need to terminate on this location.  Then  Then, for
   distance reasons, this management system may mesh Site#1 Site #1 on a PE in
   the Philadelphia PoP for
   distance reason. POP.  It may also take into account resources
   available on PEs to determine the exact target PE (e.g. (e.g., least
   loaded).
   Regarding Site#2,  For Site #2, the user is expected to configure the site-network-
   access
   site-network-access with a device-reference to CE#1, CE#1 so that the
   management system will know that the access must terminate on the
   location of CE#1 and must be connected to CE#1.  For placing placement of the service provider
   SP side of the access connection, in the case of shortest distance the nearest PE used,
   it may mesh Site #2 on the Washington PoP. POP.

6.6.3.  Constraint/parameter: access type  Constraint/Parameter: Access Type

   The management system needs to elect the access media to connect the
   site to the customer (for example : example, xDSL, leased line, Ethernet
   backhaul ...).
   backhaul).  The customer may provide some parameters/constraints that
   will provide hints to the management system.

   The bearer container information SHOULD be used as the first input : piece of
   information considered when making this decision:

   o  The "requested-type" parameter provides an information about the
      media type that the customer would like. like to use.  If the "strict"
      leaf is equal to "true", this MUST be considered as a strict constraint,
      constraint so that the management system cannot connect the site
      with another media type.  If the "strict" leaf is equal to "false" (default),
      (default) and if the requested-type requested media type cannot be fulfilled, the
      management system can select another media type.  The supported
      media types SHOULD be communicated by the
      service provider SP to the customer by via a
      mechanism that is out of scope of the for this document.

   o  The "always-on" leaf defines a strict constraint: if set to
      "true", true,
      the management system MUST elect a media type which that is
      always-on (this "always-on"
      (e.g., this means no dial access type).

   o  The "bearer-reference" parameter is used in case cases where the
      customer has already ordered a network connection to the service provider SP apart of
      from the
      IPVPN IP VPN site and wants to reuse this connection.  The
      string used in is an internal reference from the service provider describing SP and describes the
      already available
      already-available connection.  This is also a strict requirement
      that cannot be relaxed.  How the reference is given to the
      customer is out of scope of the document for this document, but as a pure example,
      when the customer ordered the bearer (through a process that is
      out of scope for this model), the service provider SP may had have provided the bearer
      reference that can be used for provisionning provisioning services on top.

   Any other internal parameters from the service provider SP can also be used
   in addition. used.  The
   management system MAY use other parameters parameters, such as the requested svc-input-bandwidth
   "svc-input-bandwidth" and svc-output-bandwidth "svc-output-bandwidth", to help to decide the
   which access type to be used. use.

6.6.4.  Constraint: access diversity Access Diversity

   Each site-network-access may have one or more constraints that would
   drive the placement of the access.  By default, the model assumes
   that there are no
   constraint constraints, but is expected allocation of a unique bearer per site-
   network-access.
   site-network-access is expected.

   In order to help with the different placement scenarios, a site-network-
   access
   site-network-access may be tagged using one or multiple group
   identifiers.  The group identifier is a string string, so it can accommodate
   both explicit naming of a group of sites (e.g. (e.g., "multihomed-set1" or
   "subVPN") or and the use of a numbered identifier (e.g. (e.g., 12345678).  The
   meaning of each group-id is local to each customer administrator.  And administrator, and
   the management system MUST ensure that different customers can use
   the same group-ids.  One or more group-ids can also be defined at the site-level,
   site level; as a consequence, all site-network-accesses under the
   site MUST inherit the group-ids of the site they are belonging belong to.  When, in
   addition to the site group-ids, group-ids some group-ids are defined at the site-
   network-access
   site-network-access level, the management system MUST consider the
   union of all groups (site level and site network access level) for
   this particular site-network-access.

   For an already configured already-configured site-network-access, each constraint MUST
   be expressed against a targeted set of site-network-accesses, this site-network-accesses.  This
   site-network-access MUST never be taken into account in the targeted
   set: e.g.
   set -- for example, "My site-network-access S must not be connected
   on the same PoP POP as the site-network-accesses that are part of group 10".
   Group 10."  The set of site-network-accesses against which the
   constraint is evaluated can be expressed as a list of groups or "all-other-
   accesses" groups,
   "all-other-accesses", or "all-other-groups".  The "all-other-accesses" all-other-accesses
   option means that the current site-network-access constraint MUST be
   evaluated against all the other site-network-accesses belonging to
   the current site.  The "all-other-groups" all-other-groups option means that the
   constraint MUST be evaluated against all groups that the current site-
   network-access is
   site-network-access does not belonging belong to.

   The current model proposes multiple constraint-types:

   o  pe-diverse: the The current site-network-access MUST not NOT be connected
      to the same PE as the targeted site-network-accesses.

   o  pop-diverse: the The current site-network-access MUST not NOT be connected
      to the same PoP POP as the targeted site-network-accesses.

   o  linecard-diverse: the The current site-network-access MUST not NOT be
      connected to the same linecard as the targeted site-network-
      accesses.
      site-network-accesses.

   o  bearer-diverse: the The current site-network-access MUST NOT use
      common bearer components compared to bearers used by the targeted
      site-network-accesses.  "bearer-diverse" provides some level of
      diversity at the access level.  As an example, two "bearer-
      diverse" bearer-diverse
      site-network-accesses must not use the same DSLAM DSLAM, BAS, or BAS
      or layer Layer 2 switch...
      switch.

   o  same-pe: the The current site-network-access MUST be connected to the
      same PE as the targeted site-network-accesses.

   o  same-bearer: the The current site-network-access MUST be connected
      using the same bearer as the targeted site-network-accesses.

   These constraint-types can be extended through augmentation.

   Each constraint is expressed as "The site-network-access S must be
   <constraint-type> (e.g. (e.g., pe-diverse, pop-diverse) from these <target>
   site-network-accesses".
   site-network-accesses."

   The group-id used to target some site-network-accesses may be the
   same as the one used by the current site-network-access.  This eases
   the configuration of scenarios where a group of site-network-access
   points has a constraint between each other. the access points in the group.  As
   an example example, if we want a set of sites (site#1 up (Site#1 to #5) Site#5) to be
   connected on different PEs, we can tag them with the same group-id
   and express a pe-diverse constraint for this group-id.

   <site>
    <site-id>SITE1</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>10</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pe-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
   <site>
    <site-id>SITE2</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>10</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pe-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
   ...
   <site>
    <site-id>SITE5</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>10</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pe-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>

   The group-id used to target some site-network-accesses may be also be
   different than the one used by the current site-network-access.  This
   can be used to express that a group of site sites has some constraints
   against another group of sites, but there is no constraint within the
   group.  As an  For example, if we consider a set of 6 six sites with two sets and two groups;
   we want to ensure that a site in the first set group must be pop-
   diverse pop-diverse
   from a site in the second set. group:

   <site>
    <site-id>SITE1</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>10</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>20</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
   <site>
    <site-id>SITE2</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>10</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>20</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
   ...
   <site>
    <site-id>SITE5</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>20</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
   <site>
    <site-id>SITE6</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>20</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>

6.6.5.  Impossible access placement  Infeasible Access Placement

   Some impossible infeasible access placement scenarios may could be created through via the
   proposed configuration framework.  Impossible  Such infeasible access placement
   scenarios could come result from too restrictive constraints that are too restrictive,
   leading to impossible infeasible access placement in the network or conflicting
   constraints that would also lead to
   impossible infeasible access placement.  An
   example of conflicting rules would be to request a that
   site-network-access#1 to be pe-diverse from a site-network-
   access#2 site-network-access#2 and to
   request at the same time that site-network-access#2
   to be on the same PE
   as site-network-access#1.  When the management system cannot
   determine the placement of a site-network-access, it SHOULD return an
   error message indicating that placement was not possible.

6.6.6.  Examples of access placement Access Placement

6.6.6.1.  Multihoming

   The customer wants to create a multihomed site.  The site will be
   composed of two site-network-accesses and site-network-accesses; for resiliency purposes, the
   customer wants the two site-network-accesses to be meshed on
   different PoPs for resiliency
   purpose.

                                        PoP#1 POPs.

                                           POP#1
       +-------+                            +---------+
       |       |                            |   PE1   |
       |       |---site_network_access#1 ----    |       |---site-network-access#1----|   PE2   |
       |       |                            |   PE3   |
       |       |                            +---------+
       | Site#1|
       |       |                                    PoP#2                               POP#2
       |       |                            +---------+
       |       |                            |   PE4   |
       |       |---site_network_access#2 ----    |       |---site-network-access#2----|   PE5   |
       |       |                            |   PE6   |
       |       |                            +---------+
       +-------+

   This scenario can be expressed in the following way: as follows:

   <site>
    <site-id>SITE1</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>10</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>20</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
     <site-network-access>
      <site-network-access-id>2</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>20</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
   But it can also be expressed as: as follows:

   <site>
    <site-id>SITE1</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <all-other-accesses/>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
     <site-network-access>
      <site-network-access-id>2</site-network-access-id>
      <access-diversity>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <all-other-accesses/>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>

6.6.6.2.  Site offload Offload

   The customer has six branch offices in a particular region region, and he
   wants to prevent to have having all branch offices to be connected on the same PE.

   He wants to express that three branch offices cannot be connected on
   the same linecard.  And  Also, the other branch offices must be connected
   on a different PoP. POP.  Those other branch offices cannot also be
   connected on the same linecard.

                                        PoP#1

                                        POP#1
                                     +---------+
                                     |   PE1   |
               Office#1 ---...       |   PE2   |
               Office#2 ---...       |   PE3   |
               Office#3 ---...       |   PE4   |
                                     +---------+

                                        PoP#2

                                        POP#2
                                     +---------+
               Office#4 ---...       |   PE4   PE5   |
               Office#5 ---...       |   PE5   PE6   |
               Office#6 ---...       |   PE6   PE7   |
                                     +---------+

   This scenario can be expressed in the following way: as follows:

   o  We need to create two sets groups of sites: set#1 Group#10, which is composed
      of Office#1 up
      to 3, set#2 Office#1, Office#2, and Office#3; and Group#20, which is
      composed of Office#4 up to 6. Office#4, Office#5, and Office#6.

   o  Sites within set#1 Group#10 must be pop-diverse from sites within set#2
      Group#20, and vice versa.

   o  Sites within set#1 Group#10 must be linecard-diverse from other sites in
      set#1
      Group#10 (same for set#2). Group#20).

   <site>
    <site-id>SITE1</site-id>
    <site-id>Office1</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>10</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>20</group-id>
          </group>
         </target>
        </constraint>
        <constraint>
         <constraint-type>linecard-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
   <site>
    <site-id>SITE2</site-id>
    <site-id>Office2</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>10</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>20</group-id>
          </group>
         </target>
        </constraint>
        <constraint>
         <constraint-type>linecard-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
   <site>
    <site-id>SITE3</site-id>
    <site-id>Office3</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>10</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>20</group-id>
          </group>
         </target>
        </constraint>
        <constraint>
         <constraint-type>linecard-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
   <site>
    <site-id>SITE4</site-id>
    <site-id>Office4</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>20</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
        <constraint>
         <constraint-type>linecard-diverse</constraint-type>
         <target>
          <group>
           <group-id>20</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
   <site>
    <site-id>SITE5</site-id>
    <site-id>Office5</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>20</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
        <constraint>
         <constraint-type>linecard-diverse</constraint-type>
         <target>
          <group>
           <group-id>20</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
   <site>
    <site-id>SITE6</site-id>
    <site-id>Office6</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>20</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
        <constraint>
         <constraint-type>linecard-diverse</constraint-type>
         <target>
          <group>
           <group-id>20</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>

6.6.6.3.  Parallel links Links

   To increase its site bandwidth at a cheaper lower cost, a customer wants to
   order two parallel site-network-accesses that will be connected to
   the same PE.

          *******SNA1**********

          *******site-network-access#1**********
   Site 1 *******SNA2********** *******site-network-access#2********** PE1

   This scenario can be expressed in the following way: as follows:

   <site>
    <site-id>SITE1</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>PE-linkgrp-1</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>same-pe</constraint-type>
         <target>
          <group>
           <group-id>PE-linkgrp-1</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNB</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
     <site-network-access>
      <site-network-access-id>2</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>PE-linkgrp-1</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>same-pe</constraint-type>
         <target>
          <group>
           <group-id>PE-linkgrp-1</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNB</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>

6.6.6.4.  SubVPN with multihoming Multihoming

   A customer has a site which that is dualhomed. dual-homed.  The dualhoming dual-homing must be
   done on two different PEs.  The customer wants also wants to implement two
   subVPNs on those multihomed accesses.

  +------------------+

   +-----------------+         Site                      +-----+                     +------+
   |                  |----------------------------------/      +----+                 |---------------------------------/       +-----+
   |                  |****(site-network-access#1)******| VPNB                 |****(site-network-access#1)*****| VPN B /       \
   | New York Office |****(site-network-access#2)*************| |****(site-network-access#2)************| VPN C   |
   |                 |                                   +----\                                  +-----\       /
   |                 |                                         +-----+
   |                 |
   |                 |                                  +------+
   |                 |                                 /       +-----+
   |                  |****(site-network-access#3)******|  VPNB                 |****(site-network-access#3)*****| VPN B /       \
   |                  |****(site-network-access#4)**************|                 |****(site-network-access#4)************| VPN C   |
   |                 |                                   +------\                                  +-----\       /
   |                 |-----------------------------------        +---+
  +------------------+      +-----+
   +-----------------+

   This scenario can be expressed in the following way: as follows:

   o  The site will have 4 four site network accesses (2 subVPN (two subVPNs coupled with
      dual homing).
      via dual-homing).

   o  Site-network-access#1 and #3 site-network-access#3 will correspond to
      the multihoming of
      the subVPN B.  A PE-diverse constraint is required
      between them.

   o  Site-network-access#2 and #4 site-network-access#4 will correspond to
      the multihoming of
      the subVPN C.  A PE-diverse constraint is required
      between them.

   o  To ensure proper usage of the same bearer for the subVPN, site-
      network-access #1
      site-network-access#1 and #2 site-network-access#2 must share the
      same bearer as site-
      network-access #3 site-network-access#3 and #4. site-network-access#4.

   <site>
    <site-id>SITE1</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>dualhomed-1</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pe-diverse</constraint-type>
         <target>
          <group>
           <group-id>dualhomed-2</group-id>
          </group>
         </target>
        </constraint>
        <constraint>
         <constraint-type>same-bearer</constraint-type>
         <target>
          <group>
           <group-id>dualhomed-1</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNB</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
     <site-network-access>
      <site-network-access-id>2</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>dualhomed-1</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pe-diverse</constraint-type>
         <target>
          <group>
           <group-id>dualhomed-2</group-id>
          </group>
         </target>
        </constraint>
        <constraint>
         <constraint-type>same-bearer</constraint-type>
         <target>
          <group>
           <group-id>dualhomed-1</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNC</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
     <site-network-access>
      <site-network-access-id>3</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>dualhomed-2</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pe-diverse</constraint-type>
         <target>
          <group>
           <group-id>dualhomed-1</group-id>
          </group>
         </target>
        </constraint>
        <constraint>
         <constraint-type>same-bearer</constraint-type>
         <target>
          <group>
           <group-id>dualhomed-2</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNB</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
     <site-network-access>
      <site-network-access-id>4</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>dualhomed-2</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pe-diverse</constraint-type>
         <target>
          <group>
           <group-id>dualhomed-1</group-id>
          </group>
         </target>
        </constraint>
        <constraint>
         <constraint-type>same-bearer</constraint-type>
         <target>
          <group>
           <group-id>dualhomed-2</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNC</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>

6.6.7.  Route Distinguisher and VRF allocation Allocation

   The route-distinguisher route distinguisher (RD) is a critical parameter of PE-based
   L3VPNs as described in [RFC4364] that allows provides the ability to
   distinguish common addressing plans in different VPNs.  As for route-targets, it is expected that route
   targets (RTs), a management system will is expected to allocate a VRF on
   the target PE and a route-
   distinguisher an RD for this VRF.

   If a VRF already exists on the target PE, PE and the VRF fulfils fulfills the
   connectivity constraints for the site, there is no need to recreate
   another VRF VRF, and the site MAY be meshed within this existing VRF.
   How the management system checks that an existing VRF fulfils fulfills the
   connectivity constraints for a site is out of scope of for this
   document.

   If no such a VRF exists on the target PE, the management system has to
   initiate the creation of a new VRF creation on the target PE and has to
   allocate a new route-distinguisher RD for this new VRF.

   The management system MAY apply a per-VPN or per-VRF allocation
   policy for the route-distinguisher RD, depending on the service provider SP's policy.  In a per-VPN
   allocation policy, all VRFs (dispatched on multiple PEs) within a VPN
   will share the same route distinguisher RD value.  In a per-VRF model, all VRFs should
   always have a unique
   route-distinguisher RD value.  Some other allocation policies are
   also possible, and this document does not restrict the allocation
   policies to be used.

   The allocation of route-distinguishers RDs MAY be done in the same way as
   route-targets. RTs.  The example
   examples provided in Section 6.2.1.1 could be
   reused. reused in this
   scenario.

   Note that a service provider an SP MAY configure a target PE for an automated allocation
   of route-distinguishers. RDs.  In this case, there will be no need for any backend system
   to allocate a route-
   distinguisher an RD value.

6.7.  Site network access availability Network Access Availability

   A site may be multihomed, meaning that it has multiple
   site-network-access points.  Placement constraints defined in
   previous sections will help
   to ensure physical diversity.

   When the site-network-accesses are placed on the network, a customer
   may want to use a particular routing policy on those accesses.

   The "site-network-access/availability" container defines parameters
   for the site redundancy.  The "access-priority" leaf defines a preference
   for a particular access.  This preference is used to model
   loadbalancing
   load-balancing or primary/backup scenarios.  The higher the access-
   priority
   access-priority value, the higher the preference will be.

   The figure below describes how the access-priority attribute can be
   used.

   Hub#1 LAN (Primary/backup)          Hub#2 LAN (Loadsharing) (Load-sharing)
     |                                                     |
     |    access-priority 1          access-priority 1     |
     |--- CE1 ------- PE1            PE3 --------- CE3 --- |
     |                                                     |
     |                                                     |
     |--- CE2 ------- PE2            PE4 --------- CE4 --- |
     |    access-priority 2          access-priority 1     |

                             PE5
                              |
                              |
                              |
                             CE5
                              |
                         Spoke#1 site (Single-homed)

   In the figure above, Hub#2 requires loadsharing load-sharing, so all the site-
   network-accesses
   site-network-accesses must use the same access-priority value.  On
   the
   contrary, other hand, as Hub#1 requires primary/backup, an a primary site-network-access and a
   backup site-network-access, a higher access-priority setting will be
   configured on the primary access.

   More site-network-access.

   Scenarios that are more complex scenarios can be modeled.  Let's consider a Hub
   site with five accesses to the network (A1,A2,A3,A4,A5).  The
   customer wants to loadshare load-share its traffic on A1,A2 in the nominal
   situation.  If A1 and A2 fails, he fail, the customer wants to loadshare load-share its
   traffic on A3 and A4, and
   finally A4; finally, if A1 to A4 are down, he wants to
   use A5.  We can model it this easily by configuring the following access-priorities:
   access-priority values: A1=100, A2=100, A3=50, A4=50, A5=10.

   The access-priority scenario has some limitation.  A limitations.  An
   access-priority scenario like the previous one with five accesses but
   with the constraint of having traffic loadshared load-shared between A3 and A4
   in the case of where A1 OR A2 being is down is not achievable.  But the
   authors consider believe that using the access-priority
   covers attribute will cover
   most of the deployment use cases and that the model can still be
   extended by via augmentation to support additional use cases.

6.8.  Traffic protection Protection

   The service model supports the ability to protect the traffic for a
   site.  A  Such protection provides a better level of availability to in
   multihoming scenarios by, for example, using local-repair techniques
   in case of failures.  The associated level of service guarantee would
   be based on an agreement between the customer and service provider the SP and is out
   of scope of for this document.

                 Site#1                            Site#2
             CE1 ----- PE1 -- P1            P3 -- PE3 ---- CE3
              |                              |             |
              |                              |             |
             CE2 ----- PE2 -- P2            P4 -- PE4 ---- CE4
                       /
                      /
             CE5 ----+
                Site#3

   In the figure above, we consider an IPVPN IP VPN service with three sites sites,
   including two dual homed dual-homed sites (site#1 (Site#1 and #2). Site#2).  For dual homed dual-homed
   sites, we consider PE1-CE1 and PE3-CE3 as primary, primary and PE2-CE2,PE4-CE4
   as backup for the example (even if protection also applies to loadsharing
   load-sharing scenarios).

   In order to protect Site#2 against a failure, a user may set the
   "traffic-protection/enabled" leaf to true for site#2. Site#2.  How the
   traffic protection will be implemented is out of scope of the for this
   document.  But as an example,  However, in such a case, if we could consider traffic coming
   from a remote site (site#1 (Site#1 or site#3), Site#3), where the primary path
   is to would
   use PE3 as the egress PE.  PE3 may have preprogrammed a backup
   forwarding entry pointing to the backup path (through PE4-CE4) for
   all prefixes going through the PE3-CE3 link.  How the backup path is
   computed is out of scope of the for this document.  When the PE3-CE3 link
   fails, traffic is still received by PE3 PE3, but PE3 switch automatically
   switches traffic to the backup entry, entry; the path will so therefore be
   PE1-P1-(...)-P3-PE3-PE4-CE4 until the remote PEs reconverge and use
   PE4 as the egress PE.

6.9.  Security

   The "security" container defines customer specific customer-specific security
   parameters for the site.  The security options supported in the model
   are limited but may be extended by via augmentation.

6.9.1.  Authentication

   The current model does not support any authentication parameters for
   the site connection, but such parameters may be added in the
   "authentication" container through augmentation.

6.9.2.  Encryption

   A traffic

   Traffic encryption can be requested on the connection.  It may be
   performed at layer Layer 2 or layer Layer 3 by selecting the appropriate
   enumeration in the "layer" leaf.  For example, a service provider an SP may use
   IPSec IPsec
   when a customer is requesting layer requests Layer 3 encryption.  The encryption profile
   can be a service provider SP defined profile or a customer specific.

   When a service provider an SP profile is used and a key (e.g. (e.g., a preshared pre-shared key) is
   allocated by the provider to be used by a customer, the
   service provider SP should
   provide a way to communicate the key in a secured way to the
   customer.

   When a customer profile is used, the model supports only preshared a pre-shared
   key for authentication authentication, with the preshared pre-shared key provided through the
   NETCONF or RESTCONF request.  A secure channel must be used to ensure
   that the preshared pre-shared key cannot be intercepted.

   It

   For security reasons, it may be necessary for the customer to change
   the preshared pre-shared key on a regular basis for security reasons. basis.  To perform a key change, the
   user can request ask the SP to change the service provider pre-shared key by submitting a new
   preshared
   pre-shared key for the site configuration (as displayed shown below).  This
   mechanism may might not to be hitless.

   <site>
    <site-id>SITE1</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <security>
       <encryption-profile>
        <preshared-key>MY_NEW_KEY</preshared-key>
       </encryption-profile>
      </security>
     </site-network-access>
    </site-network-accesses>
   </site>

   An
   A hitless key change key-change mechanism may be added through augmentation.

   Other key management methodology key-management methodologies may be added through augmentation.
   A "pki" empty container container, which is empty, has been created to help with
   support of PKI through augmentation.

6.10.  Management

   The model proposes three types of common management options:

   o  provider-managed: the The CE router is managed only by the provider.
      In this model, the responsibility boundary between the SP and the
      customer is between the CE and the customer network.

   o  customer-managed: the The CE router is managed only by the customer.
      In this model, the responsibility boundary between the SP and the
      customer is between the PE and the CE.

   o  co-managed: the The CE router is primarly primarily managed by the provider and provider; in addition
      addition, the SP lets customer accessing allows customers to access the CE for some
      configuration/monitoring purpose. purposes.  In the co-managed mode mode, the
      responsibility boundary is the same as the responsibility boundary
      for the provider-managed model.

   Based on the management model, different security options MAY be
   derived.

   In case of "co-managed", the co-managed case, the model proposes some options to define the
   management address family (IPv4 or IPv6) and the associated
   management address.

6.11.  Routing protocols

   Routing-protocol Protocols

   "routing-protocol" defines which routing protocol must be activated
   between the provider and the customer router.  The current model
   supports:
   supports the following settings: bgp, rip, ospf, static, direct,
   and vrrp.

   The routing protocol defined applies at the provider to customer provider-to-customer
   boundary.  Depending on how the management of the management model, model is administered, it
   may apply to the PE-CE boundary or CE to customer the CE-to-customer boundary.  In
   the case of a customer managed customer-managed site, the routing-protocol routing protocol defined
   will be activated between the PE and the CE router managed by the
   customer.  In the case of a provider managed provider-managed site, the routing-protocol routing
   protocol defined will be activated between the CE managed by the SP
   and the router or LAN belonging to the customer.  In this case, it is expected that we
   expect the PE-
   CE PE-CE routing will to be configured based on the service provider rules SP's rules, as
   both are managed by the same entity.

                               Rtg protocol
       192.0.2.0/24 ----- CE ----------------- PE1

                    Customer managed

                    Customer-managed site

             Rtg protocol
       Customer router ----- CE ----------------- PE1

                    Provider managed

                    Provider-managed site

   All the examples below will refer to a customer scenario for a customer-
   managed site case. site.

6.11.1.  Handling of Dual stack handling Stack

   All routing protocol types support dual stack by using address-family the
   "address-family" leaf-list.

   Example of Dual dual stack using the same routing protocol:

   <routing-protocols>
     <routing-protocol>
       <type>static</type>
       <static>
           <address-family>ipv4</address-family>
           <address-family>ipv6</address-family>
       </static>
     </routing-protocol>
   </routing-protocols>

   Example of Dual dual stack using two different routing protocols:

   <routing-protocols>
     <routing-protocol>
       <type>rip</type>
       <rip>
           <address-family>ipv4</address-family>
       </rip>
     </routing-protocol>
     <routing-protocol>
       <type>ospf</type>
       <ospf>
           <address-family>ipv6</address-family>
       </ospf>
     </routing-protocol>
   </routing-protocols>

6.11.2.  Direct  LAN connection onto Directly Connected to SP network

   Routing-protocol Network

   The routing protocol type "direct" SHOULD be used when a customer LAN
   is directly connected to the provider network and must be advertised
   in the IPVPN. IP VPN.

            LAN attached directly to provider network:

            192.0.2.0/24 ----- PE1

   In this case, the customer has a default route to the PE address.

6.11.3.  Direct  LAN connection onto Directly Connected to SP network Network with redundancy

   Routing-protocol Redundancy

   The routing protocol type "vrrp" SHOULD be used and advertised in the
   IP VPN when a

   o  the customer LAN is directly connected to the provider network and must be advertised in
   the IPVPN network,
      and

   o  LAN redundancy is expected.

         LAN attached directly to provider network with LAN redundancy:

           192.0.2.0/24 ------ PE1
                          |
                          +--- PE2

   In this case, the customer has a default route to the service
   provider SP network.

6.11.4.  Static Routing

   The routing

   Routing-protocol protocol type "static" MAY be used when a customer LAN is
   connected to the provider network through a CE router and must be
   advertised in the IPVPN. IP VPN.  In this case, the static routes give next
   hops (nh) to the CE and to the PE.  The customer has a default route
   to the SP network.

                                   Static rtg
          192.0.2.0/24 ------ CE -------------- PE
                               |                |
                               |      Static route 192.0.2.0/24 nh CE
               Static route 0.0.0.0/0 nh PE

   In this case, the customer has a default route to the service
   provider network.

6.11.5.  RIP Routing

   The routing

   Routing-protocol protocol type "rip" MAY be used when a customer LAN is
   connected to the provider network through a CE router and must be
   advertised in the IPVPN. IP VPN.  For IPv4, the model assumes usage of that RIP
   version 2. 2 is used.

   In the case of dual stack dual-stack routing requested through this model, the
   management system will be responsible to configure rip for configuring RIP (including
   right
   the correct version number) and associated address-families address families on
   network elements.

                                   RIP rtg
           192.0.2.0/24 ------ CE -------------- PE

6.11.6.  OSPF Routing

   The routing

   Routing-protocol protocol type "ospf" MAY be used when a customer LAN is
   connected to the provider network through a CE router and must be
   advertised in the IPVPN. IP VPN.

   It can be used to extend an existing OSPF network and interconnect
   different areas.  See [RFC4577] for more details.

                             +---------------------+
                             |                     |
                     OSPF    |                     | OSPF
                     area 1  |                     | area 2
    (OSPF                    |                     |          (OSPF
    area 1) --- CE ---------- PE               PE ----- CE --- area 2)
                             |                     |
                             +---------------------+

   The model also proposes an option to create an OSPF sham-link sham link between
   two sites sharing the same area and having a backdoor link.  The
   sham-link
   sham link is created by referencing the target site sharing the same
   OSPF area.  The management system will be responsible for checking to check
   see if there is already a shamlink sham link configured for this VPN and area
   between the same pair of PEs.  If there is no existing shamlink, sham link, the
   management system will provision it. one.  This shamlink sham link MAY be reused
   by other sites.

                           +------------------------+
                           |                        |
                           |                        |
                           |  PE (--shamlink--)PE (--sham link--)PE  |
                           |    |                |  |
                           +----|----------------|--+
                                | OSPF area1 area 1    | OSPF area 1
                                |                |
                                CE1             CE2
                                |                |
                          (OSPF area1) area 1)     (OSPF area1) area 1)
                                |                |
                                +----------------+

   Regarding Dual stack dual-stack support, the user MAY specify both IPv4 and IPv6
   address families, if both protocols should be routed through OSPF.
   As OSPF uses separate protocol instances for IPv4 and IPv6, the
   management system will need to configure both ospf OSPF version 2 and OSPF
   version 3 on the PE-CE link.

   Example of OSPF routing parameters in the service model. model:

   <routing-protocols>
     <routing-protocol>
       <type>ospf</type>
       <ospf>
           <area-address>0.0.0.1</area-address>
           <address-family>ipv4</address-family>
           <address-family>ipv6</address-family>
       </ospf>
     </routing-protocol>
   </routing-protocols>

   Example of PE configuration done by the management system:

   router ospf 10
    area 0.0.0.1
     interface Ethernet0/0
   !
   router ospfv3 10
    area 0.0.0.1
     interface Ethernet0/0
    !

6.11.7.  BGP Routing

   The routing

   Routing-protocol protocol type "bgp" MAY be used when a customer LAN is
   connected to the provider network through a CE router and must be
   advertised in the IPVPN. IP VPN.

                                   BGP rtg
         192.0.2.0/24 ------ CE -------------- PE

   The session addressing will be derived from connection parameters as
   well as internal the SP's knowledge of SP. the addressing plan that is in use.

   In the case of dual stack dual-stack access, the user MAY request BGP routing
   for both IPv4 and IPv6 by specifying both address-families. address families.  It will
   be up to the SP and management system to determine how to decline the
   configuration (two BGP sessions, single, multisession ...). multi-session, etc.).

   The service configuration below activates BGP on the PE-CE link for
   both IPv4 and IPv6.

   BGP activation requires the SP to know the address of the customer
   peer.  The "static-address" allocation type for the IP connection
   MUST be used.

   <routing-protocols>
     <routing-protocol>
       <type>bgp</type>
       <bgp>
           <autonomous-system>65000</autonomous-system>
           <address-family>ipv4</address-family>
           <address-family>ipv6</address-family>
       <bgp>
       </bgp>
     </routing-protocol>
   </routing-protocols>

   This service configuration can be derived by
   Depending on the SP flavor, a management system can divide this
   service configuration into
   multiple flavors depending on SP flavor. different flavors, as shown by the
   following examples.

   Example #1 of PE configuration done by the management system
   (single session IPv4 transport session):

   router bgp 100
    neighbor 203.0.113.2 remote-as 65000
    address-family ipv4 vrf Cust1
       neighbor 203.0.113.2 activate
    address-family ipv6 vrf Cust1
       neighbor 203.0.113.2 activate
       neighbor 203.0.113.2 route-map SET-NH-IPV6 out

   Example #2 of PE configuration done by the management system
   (two sessions):

   router bgp 100
    neighbor 203.0.113.2 remote-as 65000
    neighbor 2001::2 remote-as 65000
    address-family ipv4 vrf Cust1
       neighbor 203.0.113.2 activate
    address-family ipv6 vrf Cust1
       neighbor 2001::2 activate

   Example #3 of PE configuration done by the management system (multisession):
   (multi-session):

   router bgp 100
    neighbor 203.0.113.2 remote-as 65000
    neighbor 203.0.113.2 multisession per-af
    address-family ipv4 vrf Cust1
       neighbor 203.0.113.2 activate
    address-family ipv6 vrf Cust1
       neighbor 203.0.113.2 activate
       neighbor 203.0.113.2 route-map SET-NH-IPV6 out

6.12.  Service

   The service defines service parameters associated with the site.

6.12.1.  Bandwidth

   The service bandwidth refers to the bandwidth requirement between the
   PE and the CE (WAN link bandwidth).  The requested bandwidth is
   expressed as svc-input-bandwidth and svc-output-bandwidth in bits
   per seconds.
   Input/output second.  The input/output direction is using uses the customer site as a
   reference: input
   bandwidth "input bandwidth" means download bandwidth for the site,
   and output bandwidth "output bandwidth" means upload bandwidth for the site.

   The service bandwidth is only configurable at the site-network-access
   level.

   Using a different input and output bandwidth will allow service
   provider the SP to know
   determine if the customer allows for asymmetric bandwidth access
   like access,
   such as ADSL.  It can also be used to set rate-limit rate-limiting in a
   different way
   upload for uploading and download downloading on a symmetric bandwidth
   access.

   The bandwidth is a service bandwidth: bandwidth expressed primarily as IP
   bandwidth
   bandwidth, but if the customer enables MPLS for carrier's carrier, Carriers' Carriers
   (CsC), this becomes MPLS bandwidth.

6.12.2.  QoS

   The model proposes to define QoS parameters in an abstracted way:

   o  qos-classification-policy: define policy that defines a set of ordered
      rules to classify customer traffic.

   o  qos-profile: QoS scheduling profile to be applied.

6.12.2.1.  QoS classification Classification

   QoS classification rules are handled by qos-classification-policy. the
   "qos-classification-policy" container.  The qos-classification-policy
   container is an ordered list of rules that match a flow or
   application and set the appropriate target class of service
   (target-class-id).  The user can define the match using an
   application reference or a more specific flow definition (based layer that is more specific
   (e.g., based on Layer 3 source and destination address, layer addresses, Layer 4
   ports, layer and Layer 4 protocol).  When a flow definition is used, the
   user can use employ a target-sites leaf-
   list "target-sites" leaf-list to identify the
   destination of a flow rather than using destination IP addresses.  In
   such a case, an association between the site abstraction and the IP
   addresses used by this site must be done dynamically.  How this
   association is done is out of scope of for this
   document and document; an
   implementation may might not support this criterion and should advertise
   a deviation in this case.  A rule that does not have a match
   statement is considered as a match-all rule.  A service
   provider  An SP may implement a
   default terminal classification rule if the customer does not provide
   it.  It will be up to the service provider SP to determine its default target class.
   The current model defines some applications applications, but new application
   identities may be added through augmentation.  The exact meaning of
   each application identity is up to the service provider, SP, so it will be necessary
   for the service
   provider SP to advise the customer on the usage of application
   matching.

   Where the classification is done depends on the SP SP's implementation
   of the service, but classification concerns the flow coming from the
   customer site and entering the network.

                                  Provider network
                             +-----------------------+
      192.0.2.0/24
   198.51.100.0/24 ---- CE --------- PE

     Traffic flow
    ---------->

   In the figure above, the management system should implement the
   classification rule:

   o  in the ingress direction on the PE interface, if the CE is
      customer managed.
      customer-managed.

   o  in the ingress direction on the CE interface connected to the
      customer LAN, if the CE is provider managed. provider-managed.

   The figure below describes a sample service description of qos- QoS
   classification for a site : site:

   <service>
     <qos>
       <qos-classification-policy>
         <rule>
           <id>1</id>
           <match-flow>
             <ipv4-src-prefix>192.0.2.0/24</ipv4-src-prefix>
             <ipv4-dst-prefix>203.0.113.1/32</ipv4-dst-prefix>
             <l4-dst-port>80</l4-dst-port>
             <l4-protocol>tcp</l4-protocol>
           </match-flow>
           <target-class-id>DATA2</target-class-id>
         </rule>
         <rule>
           <id>2</id>
           <match-flow>
             <ipv4-src-prefix>192.0.2.0/24</ipv4-src-prefix>
             <ipv4-dst-prefix>203.0.113.1/32</ipv4-dst-prefix>
             <l4-dst-port>21</l4-dst-port>
             <l4-protocol>tcp</l4-protocol>
           </match-flow>
           <target-class-id>DATA2</target-class-id>
         </rule>
         <rule>
           <id>3</id>
           <match-application>p2p</match-application>
           <target-class-id>DATA3</target-class-id>
         </rule>
         <rule>
           <id>4</id>
           <target-class-id>DATA1</target-class-id>
         </rule>
       </qos-classification-policy>
     </qos>
   </service>

   In the example above:

   o  HTTP traffic from the 192.0.2.0/24 LAN destinated to destined for 203.0.113.1/32
      will be classified in DATA2.

   o  FTP traffic from the 192.0.2.0/24 LAN destinated to destined for 203.0.113.1/32
      will be classified in DATA2.

   o  Peer to peer  Peer-to-peer traffic will be classified in DATA3.

   o  All other traffic will be classified in DATA1.

   The order of rules is really very important.  The management system
   responsible for translating those rules in network element
   configuration MUST keep the same processing order in network element
   configuration.  The order of rule rules is defined by the "id" leaf.  The
   lowest "id" id MUST be processed first.

6.12.2.2.  QoS profile

   User Profile

   The user can choose between either a standard profile provided by the
   operator or a custom profile.  The qos-profile "qos-profile" container defines
   the traffic scheduling traffic-scheduling policy to be used by the service provider. SP.

                                  Provider network
                             +-----------------------+
   192.0.2.0/24
   198.51.100.0/24 ---- CE --------- PE
                           \       /
                          qos-profile

   In the case of provider managed a provider-managed or co-managed connection, the
   provider should ensure scheduling according to the requested policy
   in both traffic directions (SP to customer and customer to SP).  As example
   of implementation,
   an example, a device scheduling device-scheduling policy may be implemented on both
   at the
   PE side and the CE side on of the WAN link.  In the case of customer a customer-
   managed connection, the provider is only responsible to ensure for ensuring
   scheduling from the SP network to the customer site.  As example of implementation, an example,
   a device scheduling device-scheduling policy may be implemented only at on the PE side on of
   the WAN link towards the customer.

   A custom qos-profile QoS profile is defined as a list of class classes of services and
   associated properties.  The properties are:

   o  rate-limit: used to rate-limit the class of service.  The value is
      expressed as a percentage of the global service bandwidth.  When
      the qos-profile container is implemented at CE side on the CE side,
      svc-output-bandwidth is taken into account as a reference.  When
      it is implemented at on the PE side, the svc-input-bandwidth is used.

   o  latency: used to define the latency constraint of the class.  The
      latency constraint can be expressed as the lowest possible latency
      or a latency boundary expressed in milliseconds.  How this latency
      constraint will be fulfilled is up to the service provider
      implementation: SP's implementation of
      the service: a strict priority queueing queuing may be used on the access
      and in the core network, and/or a low latency low-latency routing
      configuration may be created for this traffic class.

   o  jitter: used to define the jitter constraint of the class.  The
      jitter constraint can be expressed as the lowest possible jitter
      or a jitter boundary expressed in microseconds.  How this jitter
      constraint will be fulfilled is up to the service provider
      implementation: SP's implementation of
      the service: a strict priority queueing queuing may be used on the access
      and in the core network, and/or a jitter-aware routing
      configuration may be created for this traffic class.

   o  bandwidth: used to define a guaranteed amount of bandwidth for the
      class of service.  It is expressed as a percentage.  The
      guaranteed-bw-percent
      "guaranteed-bw-percent" parameter uses available bandwidth as a
      reference.  When the qos-profile container is implemented at CE side on the svc-output-
      bandwidth
      CE side, svc-output-bandwidth is taken into account as a
      reference.  When it is implemented at on the PE side, the
      svc-input-bandwidth is used.  By default, the bandwidth
      reservation is only guaranteed at the access level.  The user can
      use the "end-to-end" leaf to request an end-to-end bandwidth reservation
      reservation, including across the MPLS transport network.  (In
      other words, the SP will activate something in the MPLS core to
      ensure that the bandwidth request from the customer will be
      fulfilled by the MPLS core as well.)  How this is done (e.g., RSVP
      reservation, controller reservation) is out of scope for this
      document.

   Some constraints may not be offered by a service provider, an SP; in this
   case case, a
   deviation should be advertised.  In addition, due to the network
   conditions, some constraints may not be completely fulfilled by the service provider,
   SP; in this case, the service provider SP should advise the customer about the
   limitations.  How this communication is done is out of scope of for this
   document.

   Example of service configuration using a standard qos QoS profile:

   <site-network-access>
    <site-network-access-id>1245HRTFGJGJ154654</site-network-access-id>
    <service>
     <svc-input-bandwidth>100000000</svc-input-bandwidth>
     <svc-output-bandwidth>100000000</svc-output-bandwidth>
     <qos>
      <qos-profile>
       <profile>PLATINUM</profile>
      </qos-profile>
     </qos>
    </service>
   </site-network-access>
   <site-network-access>
    <site-network-access-id>555555AAAA2344</site-network-access-id>
    <service>
     <svc-input-bandwidth>2000000</svc-input-bandwidth>
     <svc-output-bandwidth>2000000</svc-output-bandwidth>
     <qos>
      <qos-profile>
       <profile>GOLD</profile>
      </qos-profile>
     </qos>
    </service>
   </site-network-access>

   Example of service configuration using a custom qos QoS profile:

   <site-network-access>
    <site-network-access-id>Site1</site-network-access-id>
    <service>
     <svc-input-bandwidth>100000000</svc-input-bandwidth>
     <svc-output-bandwidth>100000000</svc-output-bandwidth>
     <qos>
      <qos-profile>
       <classes>
        <class>
         <class-id>REAL_TIME</class-id>
         <rate-limit>10</rate-limit>
         <latency>
          <use-lowest-latency/>
         </latency>
        </class>
        <class>
         <class-id>DATA1</class-id>
         <latency>
          <latency-boundary>70</latency-boundary>
         </latency>
         <bandwidth>
                            <guaranteed-bw-percent>
                            80
                            </guaranteed-bw-percent>
          <guaranteed-bw-percent>80</guaranteed-bw-percent>
         </bandwidth>
        </class>
        <class>
         <class-id>DATA2</class-id>
         <latency>
          <latency-boundary>200</latency-boundary>
         </latency>
         <bandwidth>
                            <guaranteed-bw-percent>
                            5
                            </guaranteed-bw-percent>
          <guaranteed-bw-percent>5</guaranteed-bw-percent>
          <end-to-end/>
         </bandwidth>
        </class>
       </classes>
      </qos-profile>
     </qos>
    </service>
   </site-network-access>

   The custom qos-profile QoS profile for site1 Site1 defines a REAL_TIME class with a
   latency constraint expressed as the lowest possible latency constraint. latency.  It defines also
   defines two data classes -- DATA1 and DATA2.  The two classes express
   a latency boundary constraint as well as a bandwidth reservation.  As reservation, as
   the REAL_TIME class is rate-limited to 10% of the service bandwidth
   (10% of 100Mbps 100 Mbps = 10Mbps). 10 Mbps).  In case of congestion, cases where congestion occurs, the
   REAL_TIME traffic can go up to
   10Mbps 10 Mbps (let's assume that only 5Mbps 5 Mbps
   are consumed).  DATA1 and DATA2 will share the remaining bandwidth (95Mbps)
   (95 Mbps) according to their percentage.  So  So, the DATA1 class will be
   served with at least 76Mbps 76 Mbps of bandwidth bandwidth, while the DATA2 class will
   be served with at least
   4.75Mbps. 4.75 Mbps.  The latency boundary information
   of the data class may help the service provider to SP define a specific buffer tuning or
   a specific routing within the network.  The maximum percentage to be
   used is not limited by this model but MUST be limited by the
   management system according to the policies authorized by the service
   provider. SP.

6.12.3.  Multicast

   The multicast section "multicast" container defines the type of site in the customer
   multicast service topology: source, receiver, or both.  These
   parameters will help the management system to optimize the multicast
   service.  User  Users can also define the type of multicast relation relationship
   with the customer: router (requires a protocol like such as PIM), host
   (IGMP or MLD), or both.  Address  An address family (IPv4 or IPv6 (IPv4, IPv6, or both) can
   also be defined.

6.13.  Enhanced VPN features Features

6.13.1.  Carrier's Carrier  Carriers' Carriers

   In the case of Carrier's Carrier ([RFC4364]), CsC [RFC4364], a customer may want to build an MPLS
   service using an IPVPN IP VPN to carry its traffic.

           LAN customer1
               |
               |
              CE1
               |
               | -------------
            (vrf_cust1)
             CE1_ISP1
               |                 ISP1 PoP POP
               | MPLS link
               | -------------
               |
            (vrf ISP1)
              PE1

             (...)               Provider backbone

              PE2
             (vrf ISP1)
               |
               | ------------
               |
               | MPLS link
               |                 ISP1 PoP POP
              CE2_ISP1
              (vrf_cust1)
               |-------------
               | ------------
               |
              CE2
               |
            Lan
            LAN customer1

   In the figure above, ISP1 resells IPVPN an IP VPN service but has no core
   network infrastructure between its PoPs. POPs.  ISP1 uses an IPVPN IP VPN as the
   core network infrastructure (belonging to another provider) between
   its
   PoPs. POPs.

   In order to support CsC, the VPN service must be declared indicate MPLS support using
   by setting the "carrierscarrier" leaf set to true in vpn-service. the vpn-service
   list.  The link between CE1_ISP1/PE1 and CE2_ISP1/PE2 must also run
   an MPLS signalling protocol.  This configuration is done at the site
   level.

   In the proposed model, LDP or BGP can be used as the MPLS signalling
   protocol.  In the case of LDP, an IGP routing protocol MUST also be
   activated.  In the case of BGP signalling, BGP MUST also be
   configured as
   routing-protocol.

   In case Carrier's Carrier the routing protocol.

   If CsC is enabled, the requested svc-mtu "svc-mtu" leaf will refer to the
   MPLS MTU and not to the IP MTU.

6.14.  External ID references References

   The service model sometimes refers to external information through
   identifiers.  As an example, to order a cloud-access to a particular
   Cloud Service Provider
   cloud service provider (CSP), the model uses an identifier to refer
   to the targeted CSP.  In case,  If a customer is using directly using this service
   model as an API (through REST or NETCONF NETCONF, for example) to order a
   particular service, the service provider SP should provide a list of authorized
   identifiers.  In the case of cloud-access, the service
   provider SP will provide the identifiers
   associated of identifiers for each available CSP.  The same applies to
   other identifiers like identifiers, such as std-qos-profile, oam OAM profile-name, and
   provider-profile for encryption ... encryption.

   How an SP provides the meanings of those identifiers meaning to the customer
   is out of scope of for this document.

6.15.  Defining NNIs

   An autonomous system (AS) is a single network or group of networks
   that is controlled by a common system administration group and that
   uses a single, clearly defined routing protocol.  In some cases, VPNs
   need to span across different autonomous systems ASes in different geographic areas or across span
   different service providers. SPs.  The connection between
   autonomous systems ASes is established by the Service Providers SPs
   and is seamless to the customer.

   Some examples are: Partnership  Examples include

   o  a partnership between service providers (carrier,
   cloud ...) SPs (e.g., carrier, cloud) to extend their
      VPN service seamlessly, or seamlessly.

   o  an internal administrative boundary within a single service provider (Backhaul vs
   Core vs Datacenter ...). SP (e.g.,
      backhaul versus core versus data center).

   NNIs (Network to Network Interfaces) (network-to-network interfaces) have to be defined to extend the
   VPNs across multiple autonomous systems. ASes.

   [RFC4364] defines multiple flavors of VPN NNI implementations.  Each
   implementation has different pros/cons that are pros and cons; this topic is outside the scope of
   this document.  As an example: In  For example, in an Inter-AS Option option A, ASBR autonomous
   system border router (ASBR) peers are connected by multiple
   interfaces with at least one interface
   which VPN spans of those interfaces spanning the two autonomous systems.  These
   ASes while being present in the same VPN.  In order for these ASBRs
   to signal unlabeled IP prefixes, they associate each interface with a
   VPN routing and forwarding (VRF) instance and a Border Gateway
   Protocol (BGP) session to signal unlabeled IP
   prefixes. session.  As a result, traffic between the
   back-to-back VRFs is IP.  In this scenario, the VPNs are isolated
   from each other, and because the traffic is IP, QoS mechanisms that
   operate on IP traffic can be applied to achieve customer Service Level Agreements service
   level agreements (SLAs).

     --------                 --------------              -----              -----------
    /        \               /              \            /           \
   | Cloud    |             |                |          |             |
   | Provider | ----NNI---- |                | ---NNI---|   DC |-----NNI-----|                |----NNI---| Data Center |
   |  #1      |             |                |          |             |
    \        /              |                |           \           /
     --------               |                |             ----            -----------
                            |                |
     --------               |   My network   |           -----------
    /        \              |                |          /           \
   | Cloud    |             |                |         |             |
   | Provider | ----NNI---- | |-----NNI-----|                |---NNI---|  L3VPN      |
   |  #2      |             |                |         |  Partner    |
    \        /              |                |         |             |
     --------               |                |         |             |
                             \              /          |             |
                              --------------            \           /
                                    |                     ----------                    -----------
                                    |
                                   NNI
                                    |
                                    |
                            -------------------
                           /                   \
                          |                     |
                          |                     |
                          |                     |
                          |     L3VPN partner Partner   |
                          |                     |
                           \                   /
                             ------------------
                            -------------------
   The figure above describes a service provider an SP network called "My network" that has
   several NNIs.  This network uses NNI NNIs to:

   o  increase its footprint by relying on L3VPN partners.

   o  connect its own datacenter data center services to the customer IPVPN. IP VPN.

   o  enable the customer to access to its private resources located in a
      private cloud owned by some cloud service providers. CSPs.

6.15.1.  Defining an NNI with option the Option A flavor Flavor

            AS A                                          AS B
    ---------------------                         --------------------
     -------------------                         -------------------
    /                   \                       /                   \
   |                     |                     |                     |
   |                 ++++++++ InterAS Inter-AS link ++++++++                 |
   |                 +      +_____________ +      +_______________+      +                 |
   |                 +  (VRF1)--(VPN1)----(VRF1)  (VRF1)---(VPN1)----(VRF1)  +                 |
   |                 + ASBR +               + ASBR +                 |
   |                 +  (VRF2)--(VPN2)----(VRF2)  (VRF2)---(VPN2)----(VRF2)  +                 |
   |                 +      +______________+      +_______________+      +                 |
   |                 ++++++++               ++++++++                 |
   |                     |                     |                     |
   |                     |                     |                     |
   |                     |                     |                     |
   |                 ++++++++ InterAS Inter-AS link ++++++++                 |
   |                 +      +_____________ +      +_______________+      +                 |
   |                 +  (VRF1)--(VPN1)----(VRF1)  (VRF1)---(VPN1)----(VRF1)  +                 |
   |                 + ASBR +               + ASBR +                 |
   |                 +  (VRF2)--(VPN2)----(VRF2)  (VRF2)---(VPN2)----(VRF2)  +                 |
   |                 +      +______________+      +_______________+      +                 |
   |                 ++++++++               ++++++++                 |
   |                     |                     |                     |
   |                     |                     |                     |
    \                   /                       \                   /
     --------------------
     -------------------                         -------------------

   In option A, the two ASes are connected between to each other with physical
   links on Autonomous System Border Routers (ASBR).  There ASBRs.  For resiliency purposes, there may be multiple
   physical connections between the ASes for a resiliency
   purpose. ASes.  A VPN connection, connection -- physical
   or logical (on top of physical), physical) -- is created for each VPN that needs
   to cross the AS boundary.  A back-
   to-back boundary, thus providing a back-to-back VRF model is so created.

   This model.

   From a service model's perspective, this VPN connection can be seen
   as a site from a service model
   perspective. site.  Let's say that AS B wants to extend some VPN connection connections
   for VPN C on AS A.  Administrator  The administrator of AS B can use this service
   model to order a site on AS A.  All connection scenarios could be
   realized using the features of the current model features. model.  As an example, the
   figure above,
   where above shows two physical connections are involved with that have logical
   connections per VPN overlaid on top, them.  This could be seen as a dualhomed
   dual-homed subVPN scenario.  And
   for example,  Also, the administrator from of AS B will be
   able to choose the appropriate routing protocol (e.g. ebgp) (e.g., E-BGP) to
   dynamically exchange routes between ASes.

   This document assumes that the option A NNI flavor SHOULD reuse the
   existing VPN site modeling.

   Example: a customer wants from its cloud service provider CSP A to attach its virtual network N
   to an existing IPVPN IP VPN (VPN1) that he has from a L3VPN
   service provider SP B.

           CSP A                              L3VPN SP B

     -----------------                    --------------------                    -------------------
    /                 \                  /                   \
   |       |           |                |                     |
   |  VM --|       ++++++++  NNI    ++++++++                   |----                  |--- VPN1
   |       |       +      +_________+      +                  |   Site#1
   |       |--------(VRF1)---(VPN1)--(VRF1)+                  |
   |       |       + ASBR +         + ASBR +                  |
   |       |       +      +_________+      +                  |
   |       |       ++++++++         ++++++++                  |
   |  VM --|           |                |                      |----                     |--- VPN1
   |       |Virtual    |                |                     |   Site#2
   |       |Network    |                |                     |
   |  VM --|           |                |                      |----                     |--- VPN1
   |       |           |                |                     |   Site#3
    \                 /                  \                   /
   ----------------
     -----------------                    -------------------
                                                  |
                                                  |
                                                VPN1
                                               Site#4

   The cloud service provider

   To create the VPN connectivity, the CSP or the customer may use our the
   L3VPN service model exposed by service provider that SP B to create the VPN connectivity. exposes.  We could consider that, as
   the NNI is shared, the physical connection (bearer) between CSP A and
   SP B already exists.  CSP A may request through a service model the
   creation of a new site creation with a single site-
   network-access (single homing site-network-access
   (single-homing is used in the diagram). figure).  As a placement constraint,
   CSP A may use the existing bearer reference it has from SP A to force
   the placement of the VPN NNI on the existing link.  The XML below describes what could be the
   illustrates a possible configuration request to SP B:

   <site>
       <site-id>CSP_A_attachment</site-id>
       <location>
           <city>NY</city>
           <country-code>US</country-code>
       </location>
       <site-vpn-flavor>site-vpn-flavor-nni</site-vpn-flavor>
       <routing-protocols>
         <routing-protocol>
           <type>bgp</type>
           <bgp>
               <autonomous-system>500</autonomous-system>
               <address-family>ipv4</address-family>
           </bgp>
         </routing-protocol>
       </routing-protocols>
       <site-network-accesses>
        <site-network-access>
         <site-network-access-id>CSP_A_VN1</site-network-access-id>
          <ip-connection>
           <ipv4>
            <address-allocation-type>
            static-address
            </address-allocation-type>
            <addresses>
             <provider-address>203.0.113.1</provider-address>
             <customer-address>203.0.113.2</customer-address>
             <mask>30</mask>
            </addresses>
           </ipv4>
          </ip-connection>
          <service>
           <svc-input-bandwidth>450000000</svc-input-bandwidth>
           <svc-output-bandwidth>450000000</svc-output-bandwidth>
          </service>
          <vpn-attachment>
           <vpn-id>VPN1</vpn-id>
           <site-role>any-to-any-role</site-role>
          </vpn-attachment>
        </site-network-access>
       </site-network-accesses>
       <management>
           <type>customer-managed</type>
       </management>
   </site>
   The case described above is different from a scenario using the cloud-access container
   usage
   cloud-accesses container, as the cloud-access provides a public cloud
   access while this example enables access to private resources located
   in a cloud
   service provider CSP network.

6.15.2.  Defining an NNI with option the Option B flavor Flavor

           AS A                                          AS B
    ---------------------                         --------------------
     -------------------                         -------------------
    /                   \                       /                   \
   |                     |                     |                     |
   |                 ++++++++ InterAS Inter-AS link ++++++++                 |
   |                 +      +_____________ +      +_______________+      +                 |
   |                 +      +               +      +                 |
   |                 + ASBR +<---mpebgp--->+ +<---MP-BGP---->+ ASBR +                 |
   |                 +      +               +      +                 |
   |                 +      +______________+      +_______________+      +                 |
   |                 ++++++++               ++++++++                 |
   |                     |                     |                     |
   |                     |                     |                     |
   |                     |                     |                     |
   |                 ++++++++ InterAS Inter-AS link ++++++++                 |
   |                 +      +_____________ +      +_______________+      +                 |
   |                 +      +               +      +                 |
   |                 + ASBR +<---mpebgp--->+ +<---MP-BGP---->+ ASBR +                 |
   |                 +      +               +      +                 |
   |                 +      +______________+      +_______________+      +                 |
   |                 ++++++++               ++++++++                 |
   |                     |                     |                     |
   |                     |                     |                     |
    \                   /                       \                   /
     --------------------
     -------------------                         -------------------

   In option B, the two ASes are connected between to each other with physical
   links on Autonomous System Border Routers (ASBR).  There ASBRs.  For resiliency purposes, there may be multiple
   physical connections between the ASes for a resiliency
   purpose. ASes.  The VPN "connection" between
   ASes is done by exchanging VPN routes through MP-BGP. MP-BGP [RFC4760].

   There are multiple flavors of implementations of such NNI, for an NNI.  For
   example:

   1.  The NNI is a provider internal NNI to the provider and is situated between a
       backbone and a DC. data center.  There is enough trust between the
       domains to not filter the VPN routes.  So  So, all the VPN routes are
       exchanged.  Route target  RT filtering may be implemented to save some
       unnecessary route states.

   2.  The NNI is used between providers that agreed to exchange VPN
       routes for specific route-targets RTs only.  Each provider is authorized to use
       the route-target RT values from the other provider.

   3.  The NNI is used between providers that agreed to exchange VPN
       routes for specific route-targets RTs only.  Each provider has its own route-target RT
       scheme.  So  So, a customer spanning the two networks will have
       different route-target RTs in each network for a particular VPN.

   Case 1 does not require any service modeling, as the protocol enables
   the dynamic exchange of necessary VPN routes.

   Case 2 requires to maintain some route-target filtering that an RT-filtering policy on
   ASBRs. ASBRs be maintained.
   From a service modeling point of view, it is necessary to agree on
   the list of route target RTs to authorize.

   In case Case 3, both ASes need to agree on the VPN route-target RT to
   exchange and in addition exchange, as well
   as how to map a VPN route-target RT from AS A to the corresponding route-target RT in AS B (and vice-versa).
   vice versa).

   Those modelings are currently out of scope of for this document.

     Cloud SP

          CSP A                               L3VPN SP B
           A

     -----------------                    --------------------                    ------------------
    /                 \                  /                  \
   |       |           |                |                    |
   |  VM --|       ++++++++   NNI    ++++++++                   |----                |--- VPN1
   |       |       +      +_________+      +__________+      +                |   Site#1
   |       |-------+      +          +      +                |
   |       |       + ASBR +<-mpebgp->+ +<-MP-BGP->+ ASBR +                |
   |       |       +      +_________+      +__________+      +                |
   |       |       ++++++++          ++++++++                |
   |  VM --|           |                |                      |----                    |--- VPN1
   |       |Virtual    |                |                    |   Site#2
   |       |Network    |                |                    |
   |  VM --|           |                |                      |----                    |--- VPN1
   |       |           |                |                    |   Site#3
    \                 /                 |                    |
   ----------------
     -----------------                  |                    |
                                         \                  /
                                       -------------------
                                          ------------------
                                                   |
                                                   |
                                                  VPN1
                                                 Site#4
   The example above describes an NNI connection between the service
   provider network B CSP A and a cloud service provider A. SP
   network B.  Both service
   providers SPs do not trust themselves and use a different route-target RT
   allocation policy.  So, in term terms of implementation, the customer VPN
   has a different route-target RT in each network (RT A in CSP A and RT B
   is CSP in SP
   network B).  In order to connect the customer virtual network in
   CSP A to the customer IPVPN IP VPN (VPN1) in SP B network, network B, CSP A should
   request that SP network B to open the customer VPN on the NNI (accept
   the appropriate RT).  Who does the RT translation is up to an depends on the
   agreement between the two
   service providers: SPs: SP B may permit CSP A to request VPN
   (RT) translation.

6.15.3.  Defining an NNI with option the Option C flavor Flavor

            AS A                                           AS B
    ---------------------                         --------------------
     -------------------                          -------------------
    /                   \                        /                   \
   |                     |                      |                     |
   |                     |                      |                     |
   |                     |                      |                     |
   |                 ++++++++ Multihop ebgp++++++++ E-BGP ++++++++                 |
   |                 +      +                +      +                 |
   |                 +      +                +      +                 |
   |                 + RGW  +<---mpebgp--->+  +<----MP-BGP---->+ RGW  +                 |
   |                 +      +                +      +                 |
   |                 +      +                +      +                 |
   |                 ++++++++                ++++++++                 |
   |                     |                      |                     |
   |                     |                      |                     |
   |                     |                      |                     |
   |                     |                      |                     |
   |                     |                      |                     |
   |                 ++++++++ InterAS Inter-AS link ++++++++                  |
   |                 +      +_____________ +      +_______________+      +                  |
   |                 +      +               +      +                  |
   |                 + ASBR +               + ASBR +                  |
   |                 +      +               +      +                  |
   |                 +      +______________+      +_______________+      +                  |
   |                 ++++++++               ++++++++                  |
   |                     |                      |                     |
   |                     |                      |                     |
   |                     |                      |                     |
   |                 ++++++++ InterAS Inter-AS link ++++++++                  |
   |                 +      +_____________ +      +_______________+      +                  |
   |                 +      +               +      +                  |
   |                 + ASBR +               + ASBR +                  |
   |                 +      +               +      +                  |
   |                 +      +______________+      +_______________+      +                  |
   |                 ++++++++               ++++++++                  |
   |                     |                      |                     |
   |                     |                      |                     |
    \                   /                        \                   /
     --------------------
     -------------------                          -------------------

   From a VPN service service's perspective, the option C NNI is very similar to
   option B B, as an MP-BGP session is used to exchange VPN routes between
   the ASes.  The difference is that the forwarding plane and the
   control plane are on different nodes, so the MP-BGP session is
   multihop between routing gateway (RGW) nodes.

   Modeling option

   From a VPN service's point of view, modeling options B and C will be identical from a VPN service point of
   view.
   identical.

7.  Service model usage example Model Usage Example

   As explained in Section 5, this service model is intended to be
   instantiated at a management layer and is not intended to be used
   directly on network elements.  The management system serves as a
   central point of configuration of the overall service.

   This section provides an example on of how a management system can use
   this model to configure an IPVPN IP VPN service on network elements.

   The example wants

   In this example, we want to achieve the provisionning provisioning of a VPN service
   for 3 three sites using Hub and Spoke a Hub-and-Spoke VPN service topology.  One of
   the sites will be dual homed dual-homed, and loadsharing load-sharing is expected.

   +-------------------------------------------------------------+
   |   Hub_Site  ------ PE1               PE2 ------ Spoke_Site1 |
   |      |                   +----------------------------------+
   |      |                   |
   |      |                   +----------------------------------+
   |   Hub_Site  ------ PE3               PE4 ------ Spoke_Site2 |
   +-------------------------------------------------------------+

   The following XML describes the overall simplified service
   configuration of this VPN.

   <vpn-service>
       <vpn-id>12456487</vpn-id>
       <vpn-service-topology>hub-spoke</vpn-service-topology>
   </vpn-service>
   When receiving the request for provisioning the VPN service, the
   management system will internally (or through communication with
   another OSS component) allocates allocate VPN route-targets. RTs.  In this specific
   case case, two
   RTs will be allocated (100:1 for Hub and 100:2 for Spoke).  The
   output below describes the configuration of Spoke1. Spoke_Site1.

   <site>
       <site-id>Spoke_Site1</site-id>
       <location>
           <city>NY</city>
           <country-code>US</country-code>
       </location>
       <routing-protocols>
         <routing-protocol>
           <type>bgp</type>
           <bgp>
               <autonomous-system>500</autonomous-system>
               <address-family>ipv4</address-family>
               <address-family>ipv6</address-family>
           </bgp>
         </routing-protocol>
       </routing-protocols>
       <site-network-accesses>
        <site-network-access>
         <site-network-access-id>Spoke_Site1</site-network-access-id>
         <access-diversity>
          <groups>
           <group>
            <group-id>20</group-id>
           </group>
          </groups>
          <constraints>
           <constraint>
            <constraint-type>pe-diverse</constraint-type>
            <target>
             <group>
              <group-id>10</group-id>
             </group>
            </target>
           </constraint>
          </constraints>
         </access-diversity>
         <ip-connection>
           <ipv4>
            <address-allocation-type>
            static-address
            </address-allocation-type>
            <addresses>
             <provider-address>203.0.113.254</provider-address>
             <customer-address>203.0.113.2</customer-address>
             <mask>24</mask>
            </addresses>
           </ipv4>
           <ipv6>
            <address-allocation-type>
            static-address
            </address-allocation-type>
             <addresses>
              <provider-address>2001:db8::1</provider-address>
              <customer-address>2001:db8::2</customer-address>
              <mask>64</mask>
             </addresses>
           </ipv6>
         </ip-connection>
         <service>
           <svc-input-bandwidth>450000000</svc-input-bandwidth>
           <svc-output-bandwidth>450000000</svc-output-bandwidth>
         </service>
         <vpn-attachment>
           <vpn-id>12456487</vpn-id>
           <site-role>spoke-role</site-role>
         </vpn-attachment>
        </site-network-access>
       </site-network-accesses>
       <management>
           <type>provider-managed</type>
       </management>
   </site>

   When receiving the request for provisioning Spoke1 site, Spoke_Site1, the
   management system MUST allocate network resources for this site.  It
   MUST first determine the target network elements to provision the
   access, and especially particularly the PE router (and may be perhaps also an aggregation
   switch).  As described in Section 6.6, the management system SHOULD
   use the location information and SHOULD use the access-diversity
   constraint to find the appropriate PE.  In this case, we consider
   Spoke1
   that Spoke_Site1 requires PE diversity with the Hub and that the
   management system
   allocate allocates PEs based on lowest the least distance.  Based
   on the location information, the management system finds the
   available PEs in the
   nearest area of nearest the customer and picks one that
   fits the access-
   diversity access-diversity constraint.

   When the PE is chosen, the management system needs to allocate
   interface resources on the node.  One interface is selected from the
   PE
   pool of available pool. PEs.  The management system can start provisioning
   the chosen PE node by using any mean (Netconf, CLI, ...). via whatever means the management system prefers
   (e.g., NETCONF, CLI).  The management system will check to see if a
   VRF is already present that fits the needs. its needs is already present.  If not, it will
   provision the VRF: Route distinguisher the RD will come be derived from the internal
   allocation policy model, route-targets are coming and the RTs will be derived from the
   vpn-policy VPN
   policy configuration of the site (management (the management system allocated
   some RTs for the VPN).  As the site is a Spoke site (site-role), the
   management system knows which RT RTs must be imported and exported.  As
   the site is provider managed, provider-managed, some management route-targets RTs may also be added
   (100:5000).  Standard provider VPN policies MAY also be added in the
   configuration.

   Example of generated PE configuration:

   ip vrf Customer1
    export-map STD-CUSTOMER-EXPORT      <---- Standard SP configuration
    route-distinguisher 100:3123234324
    route-target import 100:1
    route-target import 100:5000        <---- Standard SP configuration
    route-target export 100:2                    for provider managed provider-managed CE
   !

   When the VRF has been provisioned, the management system can start
   configuring the access on the PE using the allocated interface
   information.  IP addressing is chosen by the management system.  One
   address will be picked from an allocated subnet for the PE, and
   another will be used for the CE configuration.  Routing protocols
   will also be configured between the PE and CE and due to provider managed model,
   the choice CE; because this model is up
   provider-managed, the choices are left to service provider: the SP.  BGP was chosen for the
   this example.  This choice is independant independent of the routing protocol
   chosen by
   customer.  For the CE - LAN part, customer.  BGP will be used to configure the CE-to-LAN
   connection as requested in the service model.  Peering addresses will
   be derived from those of the connection.  As the CE is provider provider-
   managed, CE the CE's AS number can be automatically allocated by the
   management system.  Some provider
   standard  Standard configuration templates provided by the
   SP may also be added.

   Example of generated PE configuration:

   interface Ethernet1/1/0.10
    encapsulation dot1q 10
    ip vrf forwarding Customer1
    ip address 198.51.100.1 255.255.255.252 <---- Comes from
                                                   automated allocation
    ipv6 address 2001:db8::10:1/64
    ip access-group STD-PROTECT-IN     <---- Standard SP config
   !
   router bgp 100
    address-family ipv4 vrf Customer1
     neighbor 198.51.100.2 remote-as 65000   <---- Comes from
                                                    automated allocation
     neighbor 198.51.100.2 route-map STD in  <---- Standard SP config
     neighbor 198.51.100.2 filter-list 10 in <---- Standard SP config
   !
    address-family ipv6 vrf Customer1
     neighbor 2001:db8::0A10:2 2001:db8::0a10:2 remote-as 65000   <---- Comes from
                                                    automated allocation
     neighbor 2001:db8::0A10:2 2001:db8::0a10:2 route-map STD in  <---- Standard SP
                                                          config
     neighbor 2001:db8::0A10:2 2001:db8::0a10:2 filter-list 10 in <---- Standard SP
                                                          config
   !
   ip route vrf Customer1 192.0.2.1 255.255.255.255 198.51.100.2
   ! Static route for provider administration of CE
   !

   As the CE router is not reachable at this stage, the management
   system can produce a complete CE configuration that can be manually
   uploaded to the node by manual operation before sending the CE configuration to the
   customer
   premise. premises.  The CE configuration will be built in the same
   way as for the PE. PE would be configured.  Based on the CE type
   (vendor/model) allocated to the customer and as well as the bearer
   information, the management system knows which interface must be
   configured on the CE.  PE-CE link configuration is expected to be
   handled automatically using the service provider OSS SP OSS, as both resources are managed
   internally.  CE to LAN interface  CE-to-LAN-interface parameters
   like such as IP addressing are
   derived from the ip-connection container, taking into account how the
   management system distributes addresses between the PE and CE within
   the subnet.  This will allow to produce a plug'n'play plug-and-play configuration for the CE. CE
   to be created.

   Example of generated CE configuration:

   interface Loopback10
    description "Administration"
    ip address 192.0.2.1 255.255.255.255
   !
   interface FastEthernet10
    description "WAN"
    ip address 198.51.100.2 255.255.255.252 <---- Comes from
                                                   automated allocation
    ipv6 address 2001:db8::0A10:2/64 2001:db8::0a10:2/64
   !
   interface FastEthernet11
    description "LAN"
    ip address 203.0.113.254 255.255.255.0 <---- Comes from the
                                               ip-connection container
    ipv6 address 2001:db8::1/64
   !
   router bgp 65000
    address-family ipv4
     redistribute static route-map STATIC2BGP <---- Standard SP
                                                       configuration
     neighbor 198.51.100.1 remote-as 100     <---- Comes from
                                                 automated allocation
     neighbor 203.0.113.2 remote-as 500     <---- Comes from the
                                                 ip-connection container
    address-family ipv6
     redistribute static route-map STATIC2BGP <---- Standard SP
                                                       configuration
     neighbor 2001:db8::0A10:1 2001:db8::0a10:1 remote-as 100     <---- Comes from
                                                 automated allocation
     neighbor 2001:db8::2 remote-as 500     <---- Comes from the
                                                 ip-connection container
   !
   route-map STATIC2BGP permit 10
    match tag 10
   !

8.  Interaction with Other YANG Modules

   As expressed in Section 5, this service module model is intended to be
   instantiated in a management system and not directly on network
   elements.

   It

   The management system's role will be the role of the management system to configure the network
   elements.  The management system may be modular, so the component
   instantiating the service model (let's call it service component) "service component")
   and the component responsible for network element configuration
   (let's call it configuration component) "configuration component") may be different.

            L3VPN-SVC

             l3vpn-svc         |
              service model
               Model           |
                               |
                   +----------------------+
                    +---------------------+
                    |  Service component  | service Service datastore
                   +----------------------+
                    +---------------------+
                               |
                               |
                   +----------------------+
                    +---------------------+
               +----|  Config component   |-------+   |------+
              /     +----------------------+     +---------------------+       \   Network
             /            /            \           \  Configuration
            /            /              \           \ models
           /            /                \           \
   +++++++
   ++++++++         ++++++++       +++++++           ++++++++       ++++++++
   + CEA CE A + ------- + PE A +           + PE B + ----- + CEB CE B + Config
   +++++++
   ++++++++         ++++++++       +++++++           ++++++++       ++++++++ datastore

            Site A                              Site B

   In the previous sections, we provided some example examples of the
   translation of service provisioning request requests to router configuration lines as an
   illustration.
   lines.  In the NETCONF/YANG ecosystem, it will be expected we expect NETCONF/YANG to be
   used between the configuration component and network elements to
   configure the requested service services on these those elements.

   In this framework, it is specifications are expected from standardization to also work
   on provide specific configuration
   YANG modelization modeling of service components on network elements.  There will
   be a strong relation relationship between the abstracted view provided by this
   service model and the detailed configuration view that will be
   provided by specific configuration models for network elements.

   Authors

   The authors of this document are expecting definition anticipate definitions of YANG models
   for the network elements on listed below.  Note that this non exhaustive list of items: is not
   exhaustive:

   o  VRF definition definition, including VPN policy expression.

   o  Physical interface.

   o  IP layer (IPv4, IPv6).

   o  QoS: classification, profiles... profiles, etc.

   o  Routing protocols: support of configuration of all protocols
      listed in the document, as well as routing policies associated
      with these those protocols.

   o  Multicast VPN.

   o  Network Address Translation.

   o  ... address translation.

   Example of a VPN site request at the service level level, using this model:

   <site>
    <site-id>Site A</site-id>
    <site-network-accesses>
     <site-network-access>
      <ip-connection>
       <ipv4>
        <address-allocation-type>
        static-address
        </address-allocation-type>
        <addresses>
         <provider-address>203.0.113.254</provider-address>
         <customer-address>203.0.113.2</customer-address>
         <mask>24</mask>
        </addresses>
       </ipv4>
      </ip-connection>
      <vpn-attachment>
       <vpn-policy-id>VPNPOL1</vpn-policy-id>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
    <routing-protocols>
     <routing-protocol>
      <type>static</type>
      <static>
       <cascaded-lan-prefixes>
        <ipv4-lan-prefixes>
         <lan>198.51.100.0/30</lan>
         <next-hop>203.0.113.2</next-hop>
        </ipv4-lan-prefixes>
       </cascaded-lan-prefixes>
      </static>
     </routing-protocol>
    </routing-protocols>
    <management>
     <type>customer-managed</type>
    </management>
    <vpn-policies>
     <vpn-policy>
      <vpn-policy-id>VPNPOL1</vpn-policy-id>
      <entries>
       <id>1</id>
        <vpn>
         <vpn-id>VPN1</vpn-id>
         <site-role>any-to-any-role</site-role>
        </vpn>
       </entries>
     </vpn-policy>
    </vpn-policies>
   </site>

   In the service example above, it is expected that the service component requests is expected to
   request that the configuration component of the management system
   provide the configuration of the service elements.  If we consider
   that the service component selected a PE (PE A) as the target PE for
   the site, the configuration component will need to push the
   configuration to PE A.  The configuration component will use several
   YANG data models to define the configuration to be applied to PE A.
   The XML configuration of PE-A may PE A might look like this:

   <if:interfaces>
        <if:interface>
         <if:name>eth0</if:name>
         <if:type>ianaift:ethernetCsmacd</if:type>
         <if:description>
          Link to CEA. CE A.
         </if:description>
         <ip:ipv4>
          <ip:address>
           <ip:ip>203.0.113.254</ip:ip>
           <ip:prefix-length>24</ip:prefix-length>
          </ip:address>
          <ip:forwarding>true</ip:forwarding>
         </ip:ipv4>
        </if:interface>
   </if:interfaces>
   <rt:routing>
       <rt:routing-instance>
         <rt:name>VRF_CustA</rt:name>
         <rt:type>l3vpn:vrf</rt:type>
         <rt:type>l3vpn-network:vrf</rt:type>
         <rt:description>VRF for CustomerA</rt:description>
         <l3vpn:route-distinguisher> Customer A</rt:description>
         <l3vpn-network:route-distinguisher>
         100:1546542343
         </l3vpn:route-distinguisher>
         <l3vpn:import-rt>100:1</l3vpn:import-rt>
         <l3vpn:export-rt>100:1</l3vpn:export-rt>
         </l3vpn-network:route-distinguisher>
         <l3vpn-network:import-rt>100:1</l3vpn-network:import-rt>
         <l3vpn-network:export-rt>100:1</l3vpn-network:export-rt>
         <rt:interfaces>
          <rt:interface>
           <rt:name>eth0</rt:name>
          </rt:interface>
         </rt:interfaces>
         <rt:routing-protocols>
          <rt:routing-protocol>
           <rt:type>rt:static</rt:type>
           <rt:name>st0</rt:name>
           <rt:static-routes>
            <v4ur:ipv4>
             <v4ur:route>
              <v4ur:destination-prefix>
              198.51.100.0/30
              </v4ur:destination-prefix>
              <v4ur:next-hop>
               <v4ur:next-hop-address>
               203.0.113.2
               </v4ur:next-hop-address>
              </v4ur:next-hop>
             </v4ur:route>
            </v4ur:ipv4>
           </rt:static-routes>
          </rt:routing-protocol>
         </rt:routing-protocols>
        </rt:routing-instance>
   </rt:routing>

9.  YANG Module

   <CODE BEGINS>

   file "ietf-l3vpn-svc@2016-11-04.yang" "ietf-l3vpn-svc@2017-01-27.yang"

   module ietf-l3vpn-svc {
    namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";

    prefix l3vpn-svc;

    import ietf-inet-types {
     prefix inet;
    }

    import ietf-yang-types {
     prefix yang;
    }

    organization
     "IETF L3SM Working Group";

    contact
     "WG List: &lt;mailto:l3sm@ietf.org&gt; <mailto:l3sm@ietf.org>

     Editor:
      L3SM WG

     Chairs:
      Adrian Farrel, Qin Wu
     ";

    description
     "The
     "This YANG module defines a generic service configuration
     model for Layer 3 VPN VPNs.  This model is common across all of the
     vendor implementations.";

    revision 2016-11-03 2017-01-27 {
     description
      "Initial document"; document.";
     reference
       "RFC XXXX"; 8049.";
    }
    /* Features */

    feature cloud-access {
     description
      "Allow
      "Allows the VPN to connect to a Cloud Service
      provider."; CSP.";
    }
    feature multicast {
     description
      "Enables multicast capabilities in a VPN"; VPN.";
    }
    feature ipv4 {
     description
      "Enables IPv4 support in a VPN"; VPN.";
    }
    feature ipv6 {
     description
      "Enables IPv6 support in a VPN"; VPN.";
    }
    feature carrierscarrier {
     description
      "Enables support of carrier's carrier"; CsC.";
    }
    feature extranet-vpn {
     description
      "Enables support of extranet VPNs"; VPNs.";
    }
    feature site-diversity {
     description
      "Enables support of site diversity constraints"; constraints.";
    }
    feature encryption {
     description
      "Enables support of encryption"; encryption.";
    }
    feature qos {
     description
      "Enables support of Class classes of Services"; services.";
    }
    feature qos-custom {
     description
      "Enables support of the custom qos profile"; 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."; 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 always-on {
     description
      "Enables support for always-on of the 'always-on' access constraint.";
    }
    feature requested-type {
     description
      "Enables support for requested-type of the 'requested-type' access constraint.";
    }
    feature bearer-reference {
     description
      "Enables support for bearer-reference of the 'bearer-reference' access constraint.";
    }

    /* Typedefs */

    typedef svc-id {
     type string;
     description
      "Defining
      "Defines a type of service component
      identificators."; identifier.";
    }
    typedef template-id {
     type string;
     description
      "Defining
      "Defines a type of service template
      identificators."; identifier.";
    }

    typedef address-family {
     type enumeration {
      enum ipv4 {
       description
        "IPv4 address family"; family.";
      }
      enum ipv6 {
       description
        "IPv6 address family"; family.";
      }
     }
     description
     "Defining
      "Defines a type for address-family."; the address family.";
    }

    /* Identities */

    identity site-network-access-type {
     description
      "Base identity for site-network-access type"; type.";
    }
    identity point-to-point {
     base site-network-access-type;
     description
      "Identity for point-to-point connection"; connection.";
    }
    identity multipoint {
     base site-network-access-type;
     description
      "Identity for multipoint connection
     Example : ethernet connection.
      Example: Ethernet broadcast segment"; segment.";
    }
    identity placement-diversity {
     description
      "Base identity for site placement
      constraints"; constraints.";
    }
    identity bearer-diverse {
     base placement-diversity;
     description
      "Identity for bearer diversity.
      The bearers should not use common elements.";
    }
    identity pe-diverse {
     base placement-diversity;
     description
      "Identity for PE diversity"; diversity.";
    }
    identity pop-diverse {
     base placement-diversity;
     description
      "Identity for POP diversity"; diversity.";
    }
    identity linecard-diverse {
     base placement-diversity;
     description
      "Identity for linecard diversity"; diversity.";
    }
    identity same-pe {
     base placement-diversity;
     description
      "Identity for having sites connected on the same PE"; PE.";
    }
    identity same-bearer {
     base placement-diversity;
     description
      "Identity for having sites connected using the same bearer"; bearer.";
    }
    identity customer-application {
     description
      "Base identity for customer application"; application.";
    }
    identity web {
     base customer-application;
     description
      "Identity for web Web application (e.g. HTTP,HTTPS)"; (e.g., HTTP, HTTPS).";
    }
    identity mail {
     base customer-application;
     description
      "Identity for mail applications"; application.";
    }
    identity file-transfer {
     base customer-application;
     description
      "Identity for file transfer applications (
      e.g. application (e.g., FTP, SFTP, ...)"; SFTP).";
    }
    identity database {
     base customer-application;
     description
      "Identity for database applications"; application.";
    }
    identity social {
     base customer-application;
     description
      "Identity for social network applications"; social-network application.";
    }
    identity games {
     base customer-application;
     description
      "Identity for gaming applications"; application.";
    }
    identity p2p {
     base customer-application;
     description
      "Identity for peer to peer applications"; peer-to-peer application.";
    }
    identity network-management {
     base customer-application;
     description
      "Identity for management applications (e.g. telnet application
      (e.g., Telnet, syslog, snmp ...)"; SNMP).";
    }
    identity voice {
     base customer-application;
     description
      "Identity for voice applications"; application.";
    }
    identity video {
     base customer-application;
     description
      "Identity for video conference applications"; application.";
    }
    identity site-vpn-flavor {
     description
      "Base identity for the site VPN service flavor.";
    }
    identity site-vpn-flavor-single {
     base site-vpn-flavor;
     description
      "Base identity for the site VPN service flavor.
      Used when the site belongs to only one VPN.";
    }
    identity site-vpn-flavor-multi {
     base site-vpn-flavor;
     description
      "Base identity for the site VPN service flavor.
      Used when a logical connection of a site
      belongs to multiple VPNs.";
    }
    identity site-vpn-flavor-sub {
     base site-vpn-flavor;
     description
      "Base identity for the site VPN service flavor.
      Used when a site has multiple logical connections.
      Each of the connection may belong to different multiple VPNs.";
    }
    identity site-vpn-flavor-nni {
     base site-vpn-flavor;
     description
      "Base identity for the site VPN service flavor.
      Used to describe a an NNI option A connection.";
    }
    identity management {
     description
      "Base identity for site management scheme.";
    }
    identity co-managed {
     base management;
     description
      "Base identity for comanaged co-managed site.";
    }
    identity customer-managed {
     base management;
     description
      "Base identity for customer managed customer-managed site.";
    }
    identity provider-managed {
     base management;
     description
      "Base identity for provider managed provider-managed site.";
    }
    identity address-allocation-type {
     description
      "Base identity for address-allocation-type for PE-CE link.";
    }
    identity provider-dhcp {
     base address-allocation-type;
     description
      "Provider network provides DHCP service to customer.";
    }
    identity provider-dhcp-relay {
     base address-allocation-type;
     description
      "Provider network provides DHCP relay service to customer.";
    }
    identity provider-dhcp-slaac {
     base address-allocation-type;
     description
      "Provider network provides DHCP service to customer customer,
      as well as SLAAC.";
    }
    identity static-address {
     base address-allocation-type;
     description
      "Provider to customer
      "Provider-to-customer addressing 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 in a any to any IPVPN."; an any-to-any IP VPN.";
    }
    identity spoke-role {
     base site-role;
     description
      "Spoke Site site in a Hub & Spoke IPVPN."; Hub-and-Spoke IP VPN.";
    }
    identity hub-role {
     base site-role;
     description
      "Hub Site site in a Hub & Spoke IPVPN."; 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 any-to-any VPN topology.";
    }
    identity hub-spoke {
     base vpn-topology;
     description
      "Identity for Hub'n'Spoke Hub-and-Spoke VPN topology.";
    }
    identity hub-spoke-disjoint {
     base vpn-topology;
     description
      "Identity for Hub'n'Spoke Hub-and-Spoke VPN topology
      where Hubs cannot talk between communicate 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 BiDir bidirectional tree type.";
    }

    identity multicast-rp-discovery-type {
     description
      "Base identity for rp RP discovery type.";
    }
    identity auto-rp {
     base multicast-rp-discovery-type;
     description
      "Base identity for auto-rp Auto-RP discovery type.";
    }
    identity static-rp {
     base multicast-rp-discovery-type;
     description
      "Base identity for static type.";
    }
    identity bsr-rp {
     base multicast-rp-discovery-type;
     description
      "Base identity for BDR BSR discovery type.";
    }

    identity routing-protocol-type {
     description
      "Base identity for routing-protocol 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.";
    }
    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 is to be used when LAn LANs are directly connected
      to provider Edge PE routers.";
    }
    identity direct {
     base routing-protocol-type;
     description
      "Identity for direct protocol type.
     ."; type.";
    }

    identity protocol-type {
     description
      "Base identity 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
      "ICMP protocol type.";
    }
    identity icmp6 {
     base protocol-type;
     description
      "icmp v6
      "ICMPv6 protocol type.";
    }
    identity gre {
     base protocol-type;
     description
      "GRE protocol type.";
    }
    identity ipip {
     base protocol-type;
     description
      "IPinIP
      "IP-in-IP protocol type.";
    }
    identity hop-by-hop {
     base protocol-type;
     description
      "Hop by Hop
      "Hop-by-Hop IPv6 header type.";
    }
    identity routing {
     base protocol-type;
     description
      "Routing IPv6 header type.";
    }
    identity esp {
     base protocol-type;
     description
      "ESP header type.";
    }
    identity ah {
     base protocol-type;
     description
      "AH header type.";
    }

    /* Groupings */

    grouping vpn-service-cloud-access {
     container cloud-accesses {
     if-feature cloud-access;
     list cloud-access {

      key cloud-identifier;

      leaf cloud-identifier {
       type string;
       description
        "Identification of cloud service.
        Local
        admin administration meaning.";
      }
      choice list-flavor {
       case permit-any {
        leaf permit-any {
         type empty;
         description
         "Allow
          "Allows all sites.";
        }
       }
       case deny-any-except {
        leaf-list permit-site {
         type leafref {
          path "/l3vpn-svc/sites/site/site-id";
         }
         description
          "Site ID to be authorized.";
        }
       }
       case permit-any-except {
        leaf-list deny-site {
         type leafref {
          path "/l3vpn-svc/sites/site/site-id";
         }
         description
          "Site ID to be denied.";
        }
       }
       description
        "Choice for cloud access policy.";
      }
      container authorized-sites {
       list authorized-site {
        key site-id;

        leaf site-id {
         type leafref {
          path "/l3vpn-svc/sites/site/site-id";
         }
         description
          "Site ID.";
        }
        description
         "List of authorized sites.";
       }
       description
        "Configuration of authorized sites"; sites.";
      }
      container denied-sites {
       list denied-site {
        key site-id;

        leaf site-id {
         type leafref {
          path "/l3vpn-svc/sites/site/site-id";
         }
         description
          "Site ID.";
        }
        description
         "List of denied sites.";
       }
       description
        "Configuration of denied sites"; sites.";
      }
      container address-translation {
       container nat44 {
        leaf enabled {
         type boolean;
         default false;
         description
          "Control if
          "Controls whether or not address translation is required or not."; required.";
        }
        leaf nat44-customer-address {
         type inet:ipv4-address;
         must "../enabled = 'true'" {
          description
           "Applicable only if address translation is enabled.";
         }
         description
          "Address to be used for translation.
          This is to be used in case if the customer is
          providing the address.";
        }
        description
         "IPv4 to IPv4
         "IPv4-to-IPv4 translation.";
       }
       description
        "Container for NAT"; NAT.";
      }
      description
       "Cloud access configuration.";
     }
      description
       "Container for cloud access configurations"; configurations.";
     }
     description
      "grouping
      "Grouping for vpn VPN cloud definition"; definition.";
    }
    grouping multicast-rp-group-cfg {
     choice group-format {
      case startend {
       leaf group-start {
        type inet:ip-address;
        description
         "First group address.";
       }
       leaf group-end {
        type inet:ip-address;
        description
         "Last group address.";
       }
      }
      case singleaddress {
       leaf group-address {
        type inet:ip-address;
        description
         "Group address"; address.";
       }
      }
      description
       "Choice for group format.";
     }
     description
      "Definition of groups for
      RP to group RP-to-group mapping.";
    }

    grouping vpn-service-multicast {
     container multicast {
      if-feature multicast;
      leaf enabled {
       type boolean;
       default false;
       description
        "Enable
        "Enables multicast.";
      }
      container customer-tree-flavors {
       leaf-list tree-flavor {
         type identityref {
          base multicast-tree-type;
         }
         description
          "Type of tree to be used.";
       }
       description
        "Type of trees used by customer.";
      }
      container rp {
       container rp-group-mappings {
        list rp-group-mapping {
         key "id"; id;

         leaf id {
          type uint16;
          description
           "Unique identifier for the mapping.";
         }
         container provider-managed {
          leaf enabled {
           type boolean;
           default false;
           description
            "Set to true, true if the RP must be a
            provider
            managed provider-managed node.
            Set to false, false if it is a customer
            managed customer-managed node.";
          }
          leaf rp-redundancy {
           when "../enabled = 'true'" {
            description
             "Relevant when the RP is provider managed."; provider-managed.";
           }
           type boolean;
           default false;
           description
            "If true, a redundancy mechanism for the RP is required.";
          }
          leaf optimal-traffic-delivery {
           when "../enabled = 'true'" {
            description
             "Relevant when the RP is provider managed."; provider-managed.";
           }
           type boolean;
           default false;
           description
            "If true, the SP must ensure that
            traffic uses an optimal path.";
          }
          description
           "Parameters for provider managed a provider-managed RP.";
         }
         leaf rp-address {
          when "../provider-managed/enabled = 'false'" {
           description
            "Relevant when the RP is provider managed."; provider-managed.";
          }
          type inet:ip-address;
          description
           "Defines the address of the
          RendezvousPoint. RP.
           Used if the RP is customer managed."; customer-managed.";
         }

         container groups {
          list group {
           key id;

           leaf id {
            type uint16;
            description
             "Identifier for the group.";
           }
           uses multicast-rp-group-cfg;
           description
            "List of groups.";
          }

          description
           "Multicast groups associated with the RP.";
         }

         description
          "List of RP to group RP-to-group mappings.";
        }
        description
        "RP to group
         "RP-to-group mappings.";
       }
       container rp-discovery {
        leaf rp-discovery-type {
         type identityref {
          base multicast-rp-discovery-type;
         }
         default static-rp;
         description
          "Type of RP discovery used.";
        }
        container bsr-candidates {
         when "../rp-discovery-type = 'bsr-rp'" {
          description
           "Only applicable if discovery type is BSR-RP"; BSR-RP.";
         }
         leaf-list bsr-candidate-address {
          type inet:ip-address;
          description
           "Address of BSR candidate"; candidate.";
         }
         description
          "Customer BSR candidates address"; candidate's address.";
        }
        description
         "RP discovery parameters"; parameters.";
       }

       description
        "RendezvousPoint
        "RP parameters.";
      }
      description
       "Multicast global parameters for the VPN service.";
     }
     description
      "grouping
      "Grouping for multicast vpn definition"; VPN definition.";
    }

    grouping vpn-service-mpls {
     leaf carrierscarrier {
      if-feature carrierscarrier;
      type boolean;
      default false;
      description
       "The VPN is using Carrier's Carrier, CsC, and so MPLS is required.";
     }
     description
      "grouping
      "Grouping for mpls MPLS CsC definition"; definition.";
    }
    grouping customer-location-info {
     container locations {
      list location {
       key location-id;

       leaf location-id {
        type svc-id;
        description
         "Identifier for a particular location"; location.";
       }
       leaf address {
        type string;
        description
         "Address (number and street) of the site.";
       }
       leaf postal-code {
        type string;
        description
         "Postal code of the site.";
       }
       leaf state {
        type string;
        description
         "State of the site.  This leaf can also be used to describe
         a region for a country who that does not have
        states.
        "; states.";
       }
       leaf city {
        type string;
        description
         "City of the site.";
       }
       leaf country-code {
        type string {
         pattern '[A-Z]{2}';
        }
        description
         "Country of the site.
         Expressed as ISO ALPHA-2 code.";
       }
       description
        "Location of the site.";
       }
       description
        "List of locations for the site"; site.";
     }
     description
      "This grouping defines customer location
       parameters"; parameters.";
    }
    grouping site-group {
     container groups {
      list group {
       key group-id;

       leaf group-id {
        type string;
        description
         "Group-id the site
         is belonging to"; belongs to.";
       }
       description
        "List of group-id"; group-ids.";
      }
      description
       "Groups the site or site-network-access
       is belonging belongs to.";
     }
     description
      "Grouping definition to assign
      group-ids to site or site-network-access"; site-network-access.";
    }
    grouping site-diversity {
     container site-diversity {
       if-feature site-diversity;

       uses site-group;

       description
        "Diversity constraint type.
         Group
        All site-network-accesses will inherit the group values
        defined here will be inherited
         to all site-network-accesses."; here.";
      }
     description
      "This grouping defines site diversity
       parameters"; parameters.";
    }
    grouping access-diversity {
     container access-diversity {
       if-feature site-diversity;

       uses site-group;
       container constraints {
        list constraint {
         key constraint-type;

         leaf constraint-type {
          type identityref {
           base placement-diversity;
          }
          description
           "Diversity constraint type.";
         }
         container target {
          choice target-flavor {
           case id {
            list group {
             key group-id;

             leaf group-id {
              type string;
              description
               "The constraint will apply be applied against
               this particular
               group-id"; group-id.";
             }
             description
              "List of groups"; groups.";
            }
           }
           case all-accesses {
            leaf all-other-accesses {
             type empty;
             description
              "The constraint will apply be applied against
              all other site network
              access accesses of this site"; site.";
            }
           }
           case all-groups {
            leaf all-other-groups {
             type empty;
             description
              "The constraint will apply be applied against
              all other groups managed by the
              customer
              is managing"; customer.";
            }
           }
           description
            "Choice for the group definition"; definition.";
          }
          description
           "The constraint will apply be applied against
           this list of groups"; groups.";
         }
         description
          "List of constraints"; constraints.";
        }
        description
         "Constraints
         "Placement constraints for placing this site network access"; access.";
       }

       description
        "Diversity parameters.";
      }
     description
      "This grouping defines access diversity
       parameters"; parameters.";
    }

    grouping operational-requirements {
       leaf requested-site-start {
         type yang:date-and-time;
         description
          "Optional leaf indicating requested date and time when the
          service at a particular site is expected to start"; 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"; stop.";
        }
     description
      "This grouping defines some operational parameters
       parameters"; parameters.";
    }
    grouping operational-requirements-ops {
        leaf actual-site-start {
         type yang:date-and-time;
         config false;
         description
          "Optional leaf indicating actual date and time when the
          service at a particular site actually
       started"; started.";
        }
        leaf actual-site-stop {
         type yang:date-and-time;
         config false;
         description
          "Optional leaf indicating actual date and time when the
          service at a particular site actually
       stopped"; stopped.";
        }
     description
      "This grouping defines some operational parameters
       parameters"; parameters.";
    }

    grouping flow-definition {
     container match-flow {
      leaf dscp {
       type inet:dscp;
       description
        "DSCP value.";
      }
      leaf dot1p {
       type uint8 {
        range "0 .. 7"; "0..7";
       }
       description
        "802.1p matching.";
      }
      leaf ipv4-src-prefix {
       type inet:ipv4-prefix;
       description
        "Match on IPv4 src address.";
      }
      leaf ipv6-src-prefix {
       type inet:ipv6-prefix;
       description
        "Match on IPv6 src address.";
      }
      leaf ipv4-dst-prefix {
       type inet:ipv4-prefix;
       description
        "Match on IPv4 dst address.";
      }
      leaf ipv6-dst-prefix {
       type inet:ipv6-prefix;
       description
        "Match on IPv6 dst address.";
      }
      leaf l4-src-port {
       type inet:port-number;
       description
        "Match on layer Layer 4 src port.";
      }
      leaf-list target-sites {
       type svc-id;
       description
        "Identify a site as traffic destination.";
      }
      container l4-src-port-range {
       leaf lower-port {
        type inet:port-number;
        description
         "Lower boundary for port.";
       }
       leaf upper-port {
        type inet:port-number;
        must ". >= ../lower-port" {
         description
          "Upper boundary must be higher than lower boundary"; boundary.";
        }
        description
         "Upper boundary for port.";
       }
       description
        "Match on layer Layer 4 src port range.";
      }
      leaf l4-dst-port {
       type inet:port-number;
       description
        "Match on layer Layer 4 dst port.";
      }
      container l4-dst-port-range {
       leaf lower-port {
        type inet:port-number;
        description
         "Lower boundary for port.";
       }
       leaf upper-port {
        type inet:port-number;
        must ". >= ../lower-port" {
         description
          "Upper boundary must be higher than lower boundary"; boundary.";
        }
        description
         "Upper boundary for port.";
       }
       description
        "Match on layer Layer 4 dst port range.";
      }
      leaf protocol-field {
       type union {
        type uint8;
        type identityref {
         base protocol-type;
        }
       }
       description
        "Match on IPv4 protocol or
         Ipv6 IPv6 Next Header field.";
      }

      description
       "Describe flow matching
       criterions.";
       "Describes flow-matching criteria.";
     }
     description
      "Flow definition based on criteria.";
    }
    grouping site-service-basic {
     leaf svc-input-bandwidth {
         type uint32;
         units bps;
         description
          "From the PE PE's perspective, the service input
          bandwidth of the connection.";
     }
     leaf svc-output-bandwidth {
        type uint32;
        units bps;
        description
         "From the PE PE's perspective, the service output
         bandwidth of the connection.";
     }
     leaf svc-mtu {
      type uint16;
      units bytes;
      description
       "MTU at service level.  If the service is IP,
       it refers to the IP MTU.";
     }
     description
      "Defines basic service parameters for a site.";
    }
    grouping site-protection {
     container traffic-protection {
      if-feature fast-reroute;
      leaf enabled {
       type boolean;
       default false;
       description
        "Enables traffic protection of access link.";
      }
      description
       "Fast reroute Reroute service parameters for the site.";
     }
     description
      "Defines protection service parameters for a site.";
    }
    grouping site-service-mpls {
     container carrierscarrier {
      if-feature carrierscarrier;
      leaf signalling-type {
       type enumeration {
        enum "ldp" {
         description
          "Use LDP as the signalling protocol
          between the PE and the CE.";
        }
        enum "bgp" {
         description
          "Use BGP 3107 (as per RFC 3107) as the signalling protocol
          between the PE and the CE.
          In this case, bgp BGP must be also be configured as routing-protocol.
          ";
          the routing protocol.";
        }
       }
       description
        "MPLS signalling type.";
      }
      description
       "This container is used when the customer provides
       MPLS based
       MPLS-based services.  This is used in the case of Carrier's
       Carrier."; CsC.";
     }
     description
      "Defines MPLS service parameters for a site.";
    }
    grouping site-service-qos-profile {
     container qos {
      if-feature qos;
      container qos-classification-policy {
       list rule {
        key id;
        ordered-by user;

        leaf id {
         type uint16;
         description
          "ID of the rule.";
        }

        choice match-type {
         case match-flow {
          uses flow-definition;
         }
         case match-application {
          leaf match-application {
           type identityref {
            base customer-application;
           }
           description
            "Defines the application to match.";
          }
         }
         description
          "Choice for classification"; classification.";
        }

        leaf target-class-id {
         type string;
         description
          "Identification of the class of service.
          This identifier is internal to the administration.";
        }

        description
         "List of marking rules.";
       }
       description
        "Need to express marking rules ...";
        "Configuration of the traffic classification policy.";
      }
      container qos-profile {

       choice qos-profile {
        description
         "Choice for QoS profile.
         Can be standard profile or custom.";
        case standard {
         leaf profile {
          type string;
          description
           "QoS profile to be used"; used.";
         }
        }
        case custom {
         container classes {
          if-feature qos-custom;
          list class {
           key class-id;

           leaf class-id {
            type string;
            description
             "Identification of the class of service.
             This identifier is internal to the administration.";
           }
           leaf rate-limit {
            type uint8;
            units percent;
            description
             "To be used if the class must be rate
             limited. rate-limited.
             Expressed as percentage of the svc-bw."; service bandwidth.";
           }
           container latency {
            choice flavor {
             case lowest {
              leaf use-lowest-latency {
               type empty;
               description
                "The traffic class should use the path with the
                lowest latency path"; latency.";
              }
             }
             case boundary {
              leaf latency-boundary {
               type uint16;
               units msec;
               description
                "The traffic class should use a path with a
                defined maximum latency.";
              }
             }
             description
              "Latency constraint on the traffic
              class"; class.";
            }
            description
             "Latency constraint on the traffic
              class"; class.";
           }
           container jitter {
            choice flavor {
             case lowest {
              leaf use-lowest-jitter {
               type empty;
               description
                "The traffic class should use the path with the
                lowest jitter path"; jitter.";
              }
             }
             case boundary {
              leaf latency-boundary {
               type uint32;
               units usec;
               description
                "The traffic class should use a path with a
                defined maximum jitter.";
              }
             }
             description
              "Jitter constraint on the traffic
              class"; class.";
            }
            description
             "Jitter constraint on the traffic
              class"; class.";
           }
           container bandwidth {
            leaf guaranteed-bw-percent {
             type uint8;
             units percent;
             description
              "To be used to define the guaranteed
              BW in percent bandwidth
              as a percentage of the svc-bw
              available."; available service bandwidth.";
            }
            leaf end-to-end {
             type empty;
             description
              "Used if the bandwidth reservation
              must be done on the MPLS network too"; too.";
            }
            description
             "Bandwidth constraint on the traffic
              class"; class.";
           }
           description
            "List of class classes of services.";
          }
          description
           "Container for list of class classes of services.";
         }

        }

       }
       description
       "Qos
        "QoS profile configuration.";
      }
      description
       "QoS configuration.";
     }
     description
      "This grouping defines QoS parameters for a site"; site.";
    }

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

    }
    grouping site-security-encryption {
     container encryption {
      if-feature encryption;
      leaf enabled {
       type boolean;
       default false;
       description
        "If true, access encryption is required.";
      }
      leaf layer {
       type enumeration {
        enum layer2 {
         description
          "Encryption will occur at layer Layer 2.";
        }
        enum layer3 {
         description
          "Encryption will occur at layer Layer 3.
          IPSec
          For example, IPsec may be used as example."; used.";
        }
       }
       mandatory true;
       description
        "Layer on which encryption is applied.";
      }
      container encryption-profile {
       choice profile {
        case provider-profile {
         leaf profile-name {
          type string;
          description
           "Name of the SP profile to be applied.";
         }
        }
        case customer-profile {
         leaf algorithm {
          type string;
          description
           "Encryption algorithm to be used.";
         }
         choice key-type {
          case psk {
           leaf preshared-key {
            type string;
            description
             "Key coming from customer.";
           }
          }
          case pki {

          }
          description
           "Type of keys to be used.";
         }
        }
        description
         "Choice of profile.";
       }
       description
        "Profile of encryption to be applied.";
      }
      description
       "Encryption parameters.";
     }
     description
      "This grouping defines encryption parameters for a site"; site.";
    }

    grouping site-attachment-bearer {
     container bearer {
      container requested-type {
       if-feature requested-type;
       leaf requested-type {
        type string;
        description
         "Type of requested bearer bearer: Ethernet, DSL,
         Wireless ...
         Wireless, etc.  Operator specific.";
       }
       leaf strict {
        type boolean;
        default false;
        description
         "define if the
         "Defines whether requested-type is a preference
         or a strict requirement.";
       }
       description
        "Container for requested type."; requested-type.";
      }
      leaf always-on {
       if-feature always-on;
       type boolean;
       default true;
       description
        "Request for an always on always-on access type.
       This means
        For example, this could mean no Dial dial access type for
       example."; type.";
      }
      leaf bearer-reference {
       if-feature bearer-reference;
       type string;
       description
        "This is an internal reference for the
        service provider.

        Used "; SP.";
      }
      description
       "Bearer specific
       "Bearer-specific parameters.
       To be augmented.";
     }
     description
      "Defines physical properties of a site attachment.";
    }

    grouping site-routing {
     container routing-protocols {
      list routing-protocol {
       key type;

       leaf type {
        type identityref {
         base routing-protocol-type;
        }
        description
         "Type of routing protocol.";
       }

       container ospf {
        when "../type = 'ospf'" {
         description
          "Only applies when protocol is OSPF.";
        }
        if-feature rtg-ospf;
        leaf-list address-family {
         type address-family;

         description
          "Address family to be activated.";
        }
        leaf area-address {
         type yang:dotted-quad;
         description
          "Area address.";
        }
        leaf metric {
         type uint16;
         description
          "Metric of the PE-CE link.";
        }
        container sham-links {
         if-feature rtg-ospf-sham-link;
         list sham-link {
          key target-site;

          leaf target-site {
           type svc-id;
           description
            "Target site for the sham link connection.
            The site is referred through it's to by its ID.";
          }
          leaf metric {
           type uint16;
           description
            "Metric of the sham link.";
          }
          description
           "Creates a shamlink sham link with another
           site"; site.";
         }
         description
          "List of Sham links"; sham links.";
        }
        description
         "OSPF specific
         "OSPF-specific configuration.";
       }

       container bgp {

        when "../type = 'bgp'" {
         description
          "Only applies when protocol is BGP.";
        }
        if-feature rtg-bgp;
        leaf autonomous-system {
         type uint32;
         description
          "AS number.";
        }
        leaf-list address-family {
         type address-family;

         description
          "Address family to be activated.";
        }
        description
         "BGP specific
         "BGP-specific configuration.";
       }
       container static {
        when "../type = 'static'" {
         description
          "Only applies when protocol is static.";
        }

        container cascaded-lan-prefixes {
         list ipv4-lan-prefixes {
          if-feature ipv4;
          key "lan next-hop";

          leaf lan {
           type inet:ipv4-prefix;
           description
            "Lan
            "LAN prefixes.";
          }
          leaf lan-tag {
           type string;
           description
            "Internal tag to be used in vpn VPN policies.";
          }
          leaf next-hop {
           type inet:ipv4-address;
           description
            "Nexthop
            "Next-hop address to use at on the customer side.";
          }
          description "
           List
           "List of LAN prefixes for the site.
           "; site.";
         }
         list ipv6-lan-prefixes {
          if-feature ipv6;
          key "lan next-hop";

          leaf lan {
           type inet:ipv6-prefix;
           description
            "Lan
            "LAN prefixes.";
          }
          leaf lan-tag {
           type string;
           description
            "Internal tag to be used in vpn VPN policies.";
          }
          leaf next-hop {
           type inet:ipv6-address;
           description
            "Nexthop
            "Next-hop address to use at on the customer side.";
          }
          description "
           List
           "List of LAN prefixes for the site.
           "; site.";
         }
         description
          "LAN prefixes from the customer.";
        }
        description
         "Static routing
         "Configuration specific configuration."; to static routing.";
       }
       container rip {

        when "../type = 'rip'" {
         description
          "Only applies when protocol is RIP.";
        }
        if-feature rtg-rip;
        leaf-list address-family {
         type address-family;

         description
          "Address family to be activated.";
        }

        description
         "RIP routing
         "Configuration specific
         configuration."; to RIP routing.";
       }

       container vrrp {

        when "../type = 'vrrp'" {
         description
          "Only applies when protocol is VRRP.";
        }
        if-feature rtg-vrrp;
        leaf-list address-family {
         type address-family;

         description
          "Address family to be activated.";
        }
        description
         "VRRP routing
         "Configuration specific configuration."; to VRRP routing.";
       }

       description
        "List of routing protocols used on
        the site.
        Need to  This list can be augmented.";
      }
      description
       "Defines routing protocols.";
     }
     description
      "Grouping for routing protocols.";
    }

    grouping site-attachment-ip-connection {
     container ip-connection {
      container ipv4 {
       if-feature ipv4;
       leaf address-allocation-type {
        type identityref {
         base address-allocation-type;
        }
        default "static-address";
        description
         "Defines how addresses are allocated.
         "; allocated.";
       }

       leaf number-of-dynamic-address {
        when "../address-allocation-type = 'provider-dhcp'" {
         description
          "Only applies when addresses are dhcp allocated"; allocated by DHCP.";
        }
        type uint8;
        default 1;
        description
         "Describes the number of IP addresses the customer requires"; requires.";
       }
       container dhcp-relay {
        when "../address-allocation-type = 'provider-dhcp-relay'" {
         description
          "Only applies when provider is required to implementations implement
          DHCP relay function"; function.";
        }
        container customer-dhcp-servers {
         leaf-list server-ip-address {
          type inet:ipv4-address;
          description
           "IP address of customer DHCP server"; server.";
         }
         description
          "Container for list of customer DHCP server"; servers.";
        }
        description
         "DHCP relay provided by operator.";
       }
       container addresses {
        when "../address-allocation-type = 'static-address'" {
         description
          "Only applies when protocol allocation type is static"; static.";
        }
        leaf provider-address {
         type inet:ipv4-address;
         description
          "Provider side address.";
          "Address of provider side.";
        }
        leaf customer-address {
         type inet:ipv4-address;
         description
          "Customer side address.";
          "Address of customer side.";
        }
        leaf mask {
         type uint8 {
          range "0..31";
         }
         description
          "Subnet mask expressed in bits"; bits.";
        }
        description
         "Describes IP addresses used"; used.";
       }

       description
        "IPv4 specific parameters";
        "IPv4-specific parameters.";

      }
      container ipv6 {
       if-feature ipv6;
       leaf address-allocation-type {
        type identityref {
         base address-allocation-type;
        }
        default "static-address";
        description
         "Defines how addresses are allocated.
         "; allocated.";
       }
       leaf number-of-dynamic-address {
        when
        "../address-allocation-type = 'provider-dhcp' "+
        "or ../address-allocation-type "+
        "= 'provider-dhcp-slaac'" {
         description
          "Only applies when addresses are dhcp allocated"; allocated by DHCP.";
        }
        type uint8;
        default 1;
        description
         "Describes the number of IP addresses the customer requires"; requires.";
       }
       container dhcp-relay {
        when "../address-allocation-type = 'provider-dhcp-relay'" {
         description
          "Only applies when provider is required to implementations implement
          DHCP relay function"; function.";
        }
        container customer-dhcp-servers {
         leaf-list server-ip-address {
          type inet:ipv6-address;
          description
           "IP address of customer DHCP server"; server.";
         }
         description
          "Container for list of customer DHCP server"; servers.";
        }
        description
         "DHCP relay provided by operator.";
       }
       container addresses {
        when "../address-allocation-type = 'static-address'" {
         description
          "Only applies when protocol allocation type is static"; static.";
        }
        leaf provider-address {
         type inet:ipv6-address;
         description
          "Provider side address.";
          "Address of provider side.";
        }
        leaf customer-address {
         type inet:ipv6-address;
         description
          "Customer side address.";
          "Address of customer side.";
        }
        leaf mask {
         type uint8 {
          range "0..127";
         }
         description
          "Subnet mask expressed in bits"; bits.";
        }
        description
         "Describes IP addresses used"; used.";
       }
       description
        "IPv6 specific parameters";
        "IPv6-specific parameters.";

      }
      container oam {
       container bfd {
        if-feature bfd;
        leaf enabled {
         type boolean;
         default false;
         description
          "BFD activation"; activation.";
        }

        choice holdtime {
         case profile {
          leaf profile-name {
           type string;
           description
            "Service provider well
            known
            "Well-known SP profile.";
          }
          description
            "Service provider well
            known
           "Well-known SP profile.";
         }
         case fixed {
          leaf fixed-value {
           type uint32;
           units msec;
           description
            "Expected holdtime expressed in msec.";
          }
         }
         description
          "Choice for holdtime flavor.";
        }
        description
         "Container for BFD.";
       }
       description
        "Define
        "Defines the OAM mechanisms used on the connection.";
      }
      description
       "Defines connection parameters.";
     }
     description
      "This grouping defines IP connection parameters.";
    }
    grouping site-service-multicast {
     container multicast {
      if-feature multicast;
      leaf multicast-site-type {
       type enumeration {
        enum receiver-only {
         description
          "The site has only has receivers.";
        }
        enum source-only {
         description
          "The site has only has sources.";
        }
        enum source-receiver {
         description
          "The site has both sources & and receivers.";
        }
       }
       default "source-receiver";
       description
        "Type of multicast site.";
      }
      container multicast-address-family {
       leaf ipv4 {
        if-feature ipv4;
        type boolean;
        default true;
        description
         "Enables ipv4 multicast"; IPv4 multicast.";
       }
       leaf ipv6 {
        if-feature ipv6;
        type boolean;
        default false;
        description
         "Enables ipv6 multicast"; IPv6 multicast.";
       }
       description
        "Defines protocol to carry multicast.";
      }
      leaf protocol-type {
       type enumeration {
        enum host {
         description
          "
          Hosts
          "Hosts are directly connected to the provider network.
          Host protocols like IGMP, such as IGMP or MLD are required.
          "; required.";
        }
        enum router {
         description
          "
          Hosts
          "Hosts are behind a customer router.
          PIM will be implemented.
          "; implemented.";
        }
        enum both {
         description
          "Some Hosts hosts are behind a customer
          router router, and some others
          are directly connected to the provider network.
          Both host and routing protocols must be used. Typically
          Typically, IGMP and PIM will be
          implemented.
          "; implemented.";
        }
       }
       default "both";
       description
        "Multicast protocol type to be used with the customer site.";
      }

      description
       "Multicast parameters for the site.";
     }
     description
      "Multicast parameters for the site.";
    }

    grouping site-management {
     container management {
      leaf type {
       type identityref {
        base management;
       }
       description
        "Management type of the connection.";
      }
      description
       "Management configuration"; configuration.";
     }
     description
      "Management parameters for the site.";
    }
    grouping site-devices {
     container devices {
      must "/l3vpn-svc/sites/site/management/type = "+
       "'provider-managed' or "+
       "/l3vpn-svc/sites/site/management/type ="+ = "+
       "'co-managed'" {
        description
         "Applicable only for provider-managed or co-managed device"; device.";
       }
      list device {
       key device-id;

       leaf device-id {
        type svc-id;
        description
         "identifier
         "Identifier for the device"; device.";
       }
       leaf location {
        type leafref {
         path "/l3vpn-svc/sites/site/locations/"+
          "location/location-id";
        }
        description
         "Location of the device"; device.";
       }
       container management {
        must "/l3vpn-svc/sites/site/management/type"+
         "= 'co-managed'" {
          description
           "Applicable only for co-managed device"; device.";
         }
        leaf address-family {
         type address-family;

         description
          "Address family used for management.";
        }
        leaf address {
         type inet:ip-address;
         description
          "Management address"; address.";
        }
        description
         "Management configuration. Only  Applicable only for
         co-managed case."; device.";
       }
       description
        "Device configuration"; configuration.";
      }
      description
       "List of devices requested by customer"; customer.";
     }
     description
      "Grouping for device allocation"; allocation.";
    }
    grouping site-vpn-flavor {
     leaf site-vpn-flavor {
      type identityref {
       base site-vpn-flavor;
      }
      default site-vpn-flavor-single;
      description
       "Defines if whether the site
      is is, for example,
       a single VPN site, or multiVPN site or ..."; a multiVPN.";
     }
     description
      "Grouping for site-vpn-flavor."; site VPN flavor.";
    }

    grouping site-vpn-policy {
     container vpn-policies {
      list vpn-policy {
       key vpn-policy-id;

       leaf vpn-policy-id {
        type svc-id;
        description
         "Unique identifier for the VPN policy.";
       }

       list entries {
        key id;

        leaf id {
          type svc-id;
          description
           "Unique identifier for the policy entry.";
        }
        container filter {
         choice lan {
          case prefixes {
           leaf-list ipv4-lan-prefix {
            if-feature ipv4;
            type inet:ipv4-prefix;
            description
             "List of IPv4 prefixes to be matched.";
           }
           leaf-list ipv6-lan-prefix {
            if-feature ipv6;
            type inet:ipv6-prefix;
            description
             "List of IPv6 prefixes to be matched.";
           }
          }
          case lan-tag {
           leaf-list lan-tag {
            type string;
            description
             "List of lan-tags 'lan-tag' items to be matched.";
           }
          }
          description
           "Choice for of ways to do LAN matching type"; matching.";
         }
         description
          "If used, it permit to split permits the splitting of
          site LANs among multiple VPNs.
          If no filter is used, all the LANs will be
          part of the same VPNs with the same role.";
        }
        container vpn {
         leaf vpn-id {
          type leafref {
           path "/l3vpn-svc/vpn-services/"
           +"vpn-service/vpn-id"; "/l3vpn-svc/vpn-services/"+
           "vpn-service/vpn-id";
          }
          mandatory true;
          description
           "Reference to an IPVPN."; IP VPN.";
         }
         leaf site-role {
          type identityref {
           base site-role;
          }
          default any-to-any-role;
          description
           "Role of the site in the IPVPN."; IP VPN.";
         }
         description
          "List of VPNs the LAN is associated to."; with.";
        }
        description
         "List of entries for export policy.";
       }
       description
        "List of VPN policies.";
      }
      description
       "VPN policy.";
     }
     description
      "VPN policy parameters for the site.";
    }

    grouping site-maximum-routes {
     container maximum-routes {
      list address-family {
       key af;

       leaf af {
        type address-family;

        description
         "Address-family.";
         "Address family.";
       }
       leaf maximum-routes {
        type uint32;
        description
         "Maximum prefixes the VRF can accept for this
         address-family."; address family.";
       }
       description
        "List of address families.";
      }

      description
       "Define maximum-routes
       "Defines 'maximum-routes' for the VRF.";
     }
     description
     "Define maximum-routes
      "Defines 'maximum-routes' for the site.";
    }

    grouping site-security {
     container security {
      uses site-security-authentication;
      uses site-security-encryption;

      description
       "Site specific
       "Site-specific security parameters.";
     }
     description
      "Grouping for security parameters.";
    }

    grouping site-service {
     container service {
      uses site-service-qos-profile;
      uses site-service-mpls;
      uses site-service-multicast;

      description
       "Service parameters on the attachement."; attachment.";
     }
     description
      "Grouping for service parameters.";
    }

    grouping site-network-access-service {
     container service {
      uses site-service-basic;
      uses site-service-qos-profile;
      uses site-service-mpls;
      uses site-service-multicast;

      description
       "Service parameters on the attachement."; attachment.";
     }
     description
      "Grouping for service parameters.";
    }
    grouping vpn-extranet {
     container extranet-vpns {
      if-feature extranet-vpn;
      list extranet-vpn {
       key vpn-id;

       leaf vpn-id {
        type svc-id;
        description
         "Identifies the target VPN"; VPN.";
       }
       leaf local-sites-role {
        type identityref {
         base site-role;

        }
        default any-to-any-role;
        description
         "This describes the role of the
         local sites in the target VPN topology.";
       }
       description
        "List of extranet VPNs the local VPN is attached to.";
      }
      description
       "Container for extranet vpn cfg."; VPN configuration.";
     }
     description
      "grouping
      "Grouping for extranet VPN configuration.
      Extranet
      This provides a an easy way to interconnect
      all sites from two VPNs in a easy way."; VPNs.";
    }

    grouping site-attachment-availability {
     container availability {
      leaf access-priority {
       type uint32;
       default 1;
       description
        "Defines the priority for the access.
        The highest higher the priority value is, access-priority value,
        the highest higher the preference of the access is."; will be.";
      }
      description
       "Availability parameters (used for multihoming)"; multihoming).";
     }
     description
      "Defines site availability parameters."; parameters for a site.";
    }

    grouping access-vpn-policy {
     container vpn-attachment {

      choice attachment-flavor {
       case vpn-policy-id {
        leaf vpn-policy-id {
         type leafref {
          path "/l3vpn-svc/sites/site/"+
          "vpn-policies/vpn-policy/"+
          "vpn-policy-id";
         }
         description
          "Reference to a VPN policy.";
        }
       }
       case vpn-id {
        leaf vpn-id {
         type leafref {
          path "/l3vpn-svc/vpn-services"+
          "/vpn-service/vpn-id";
         }
         description
          "Reference to a VPN.";
        }
        leaf site-role {
         type identityref {
           base site-role;
          }
         default any-to-any-role;
         description
          "Role of the site in the IPVPN."; IP VPN.";
        }
       }
       mandatory true;
       description
        "Choice for VPN attachment flavor.";
      }
      description
       "Defines VPN attachment of a site.";
     }
     description
      "Defines the VPN attachment rules for a site site's logical access.";
    }
    grouping vpn-svc-cfg {
     leaf vpn-id {
       type svc-id;
       description
        "VPN identifier.  Local administration meaning.";
      }
      leaf customer-name {
       type string;
       description
        "Name of the customer.";
      }
     leaf vpn-service-topology {
      type identityref {
       base vpn-topology;
      }
      default "any-to-any";
      description
       "VPN service topology.";
     }

     uses vpn-service-cloud-access;
     uses vpn-service-multicast;
     uses vpn-service-mpls;
     uses vpn-extranet;

     description
      "grouping
      "Grouping for vpn-svc VPN service configuration.";
    }

    grouping site-top-level-cfg {
     uses operational-requirements;
     uses customer-location-info;
     uses site-devices;
     uses site-diversity;
     uses site-management;
     uses site-vpn-policy;
     uses site-vpn-flavor;
     uses site-maximum-routes;
     uses site-security;
     uses site-service;
     uses site-protection;
     uses site-routing;

     description
      "Grouping for site top level cfg."; top-level configuration.";
    }
    grouping site-network-access-top-level-cfg {
     leaf site-network-access-type {
      type identityref {
       base site-network-access-type;
      }
      default "point-to-point";
      description
       "Describes the type of connection, e.g. : e.g.,
       point-to-point or multipoint"; multipoint.";
     }

     choice location-flavor {
      case location {
       when "/l3vpn-svc/sites/site/management/type = "+
         "'customer-managed'" {
          description
           "Applicable only for customer-managed"; customer-managed device.";
        }
       leaf location-reference {
        type leafref {
         path "/l3vpn-svc/sites/site/locations/"+
            "location/location-id";
        }
        description
         "Location of the site-network-access"; site-network-access.";
       }
      }
      case device {
       when "/l3vpn-svc/sites/site/management/type = "+
         "'provider-managed' or "+
         "/l3vpn-svc/sites/site/management/type = "+
         "'co-managed'" {
          description
           "Applicable only for provider-managed or co-managed device"; device.";
        }
       leaf device-reference {
        type leafref {
         path "/l3vpn-svc/sites/site/devices/"+
            "device/device-id";
        }
        description
         "Identifier of CE to use"; use.";
       }
      }
      mandatory true;
      description
       "Choice on of how to describe the site location"; site's location.";
     }
     uses access-diversity;
     uses site-attachment-bearer;
     uses site-attachment-ip-connection;
     uses site-security;
     uses site-network-access-service;
     uses site-routing;
     uses site-attachment-availability;
     uses access-vpn-policy;

     description
      "Grouping for site network access
      top level cfg."; top-level configuration.";
    }

    /* Main blocks */

    container l3vpn-svc {
     container vpn-services {
      list vpn-service {
       key vpn-id;

       uses vpn-svc-cfg;

       description "
        List
        "List of VPN services.
       "; services.";
      }
      description
       "top level
       "Top-level container for the VPN services.";
     }

     container sites {
      list site {
       key site-id;

       leaf site-id {
        type svc-id;
        description
         "Identifier of the site.";
       }

       uses site-top-level-cfg;
       uses operational-requirements-ops;
       container site-network-accesses {
        list site-network-access {
         key site-network-access-id;

         leaf site-network-access-id {
          type svc-id;
          description
           "Identifier for the access"; access.";
         }
         uses site-network-access-top-level-cfg;

         description
          "List of accesses for a site.";
        }
        description
         "List of accesses for a site.";
       }

       description
        "List of sites.";
      }
      description
       "Container for sites"; sites.";
     }

     description
      "Main container for L3VPN service configuration.";
    }

   }
   <CODE ENDS>

10.  Security Considerations

   The YANG modules module defined in this document MAY be accessed via the
   RESTCONF protocol [I-D.ietf-netconf-restconf] [RFC8040] or the NETCONF protocol
   ([RFC6241]. [RFC6241].  The
   lowest RESTCONF or NETCONF layer requires that the transport-layer
   protocol provides provide both data integrity and
   confidentiality, confidentiality; see
   Section 2 in [I-D.ietf-netconf-restconf] [RFC8040] and Section 2 in [RFC6241].  The client MUST
   carefully examine the certificate presented by the server to
   determine if it meets the client's expectations, and the server MUST
   authenticate client access to any protected resource.  The client
   identity derived from the authentication mechanism used is subject to
   the NETCONF Access Control Module Model (NACM) ([RFC6536]). [RFC6536].  Other protocols
   that are used to access this YANG module are also required to support the
   similar mechanism. security mechanisms.

   The data nodes defined in the "ietf-l3vpn-svc" YANG module MUST be
   carefully created/read/updated/deleted. created, read, updated, or deleted as appropriate.  The
   entries in the lists below include customer proprietary customer-proprietary or
   confidential information,
   therefore only authorized clients MUST information; therefore, access the to confidential
   information MUST be limited to authorized clients, and the other clients
   MUST NOT be able permitted to access the information.

   o  /l3vpn-svc/vpn-services/vpn-service

   o  /l3vpn-svc/sites/site

   The data model proposes some security parameters than can be extended
   by
   via augmentation as part of the customer service request: request; those
   parameters are described in Section 6.9.

11.  Contribution

   Authors would like to thank Rob Shakir for his major contribution on
   the initial modeling and use cases.

12.  Acknowledgements

   Thanks to Qin Wu, Maxim Klyus, Luis Miguel Contreras, Gregory Mirsky,
   Zitao Wang, Jing Zhao, Kireeti Kompella, Eric Rosen, Aijun Wang,
   Michael Scharf, Xufeng Liu, David Ball, Lucy Yong, Jean-Philippe
   Landry and Andrew Leu for the contributions to the document.

13.  IANA Considerations

   IANA is requested to assign has assigned a new URI from the IETF "IETF XML registry
   ([RFC3688]).  Authors are suggesting the following URI:

       ID: yang:ietf-l3vpn-svc Registry" [RFC3688].

      URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc
       Filename: [ TBD-at-registration ]
       Reference: [ RFC-to-be ]
      Registrant Contact: L3SM WG The IESG
      XML: N/A, N/A; the requested URI is an XML namespace namespace.

   This document also requests adds a new YANG module name in the YANG "YANG Module
   Names Names"
   registry ([RFC7950]) with the following suggestion: [RFC6020]:

      Name: ietf-l3vpn-svc
      Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc
      Prefix: l3vpn-svc
       Module:
      Reference: [ RFC-to-be ]

14.  Change Log

14.1.  Changes between versions -18 and-19

   o  Country code string pattern enforced to ISO ALPHA-2 code.

   o  zip-code renamed to postal-code.

   o  Added new address-allocation-type: provider-dhcp-slaac.

   o  Removed transport-constraints and include transport constraints
      (jitter,latency, bandwidth) in the qos-profile.

   o  qos-profile simplified with more abstraction.

   o  added target-sites in flow-definition.

14.2.  Changes between versions -17 and-18

   o  Removed TOS from flow matching.

14.3.  Changes between versions -16 and-17

   o  Renamed "vpn-svc" list to "vpn-service".

   o  Renamed "vpn-policy-list" to "vpn-policies".

   o  Renamed "management-transport" to "address-family".

   o  Renamed "multicast-transport" to "address-family".

   o  Modified cloud access policy using a choice.

   o  any-to-any-role as default site-role.

   o  "address-family" is now an enumeration instead of identity.

   o  cloud-access feature moved to container level.

   o  Added "address-translation" container for cloud-access.

   o  Renamed "customer-nat-address" to "customer-address".

   o  New type ip:address RFC 8049

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for "customer-address".

   o  "tree-flavor" moved to leaf-list.

   o  "bsr-candidate" list moved to "bsr-candidate-address" leaf-list.

   o  layer becomes mandatory in security-encryption.

   o  ip-subnet mask range modified.

   o  multicast transport constraint destination moved to leaf-list.

   o  lan-prefixes in vpn-policy moved to leaf-list ang tag has been
      renamed "prefixes".

   o  Added source and destination port range in QoS classification.

   o  QoS classification uses more existing inet:types.

   o  Grouping defined for site group list.

14.4.  Changes between versions -15 and-16

   o  Rename "topology" leaf to "vpn-service-topology".

14.5.  Changes between versions -13 and-14

   o  Choice between device reference and location reference.

14.6.  Changes between versions -12 and-13

   o  Removed rip-ng identity (rip container has AF information)

   o  renamed pe-dhcp to provider-dhcp

   o  add provider-dhcp-relay identity and container

   o  BW/MTU is now only under site-network-access

   o  Add list of location and location ID

   o  Site-network-access mapped to location Identifier

   o  Add list of devices (provided by operator) requested by customer

   o  Some management parameters moved under device list

   o  Site-network-access mapped to device identifier

14.7.  Changes between versions -11 and-12

   o  Fixing some 'when' statements that prevented compilation.

14.8.  Changes between versions -09 and-10

   o  Removed templates.

   o  Add site-network-access-type.

   o  Add a leaf number-of-dynamic-address in case of pe-dhcp
      addressing.

14.9.  Changes between versions -08 and-09

   o  Add site-vpn-flavor NNI.

14.10.  Changes between versions -07 and-08

   o  Traffic protection moved to site level.

   o  Decouple operational-requirements in two containers.

14.11.  Changes between versions -06 and-07

   o  Set config false to actual-site-start and stop.

   o  Add a container before cloud-access list.

   o  Add a container before authorized-sites list.

   o  Add a container before denied-sites list.

   o  Modified access-diversity modeling.

   o  Replacing type placement diversity by an identity.

14.12.  Changes between versions -05 and-06

   o  Added linecard diverse for site diversity

   o  Added a new diversity enum in placement-diversity: none

   o  Added state to site location

   o  remove reference to core routing model: created new address family
      identities

   o  added features

   o  Modified bearer parameters

   o  Modified union for ipv4/ipv6 addresses to ip-address type

   o  Add BSR parameters for multicast

   o  Add applications matching for QoS classification

14.13.  Changes between versions -04 and-05

   o  Modify VPN policy and creating a vpn-policy-list

   o  Add VPN policy reference and VPN ID reference under site-network-
      access

14.14.  Changes between versions -02 and-03

   o  Add extranet-vpn container in vpn-svc

   o  Creating top level containers

   o  Refine groupings

   o  Added site-vpn-flavor

   o  qos-profile moved to choice

   o  vpn leaf moved to vpn-id in vpn-policy

   o  added ordered-by user to qos classification list

   o  moved traffic protection to access availability

   o  creating a choice in matching filter for VPN policy

   o  added dot1p matching field in flow-definition

14.15.  Changes between versions -01 and-02

   o  A site is now a collection of site-accesses.  This was introduced
      to support M to N availability.

   o  Site-availability has been removed, replaced by availability
      parameters under site-accesses

   o  Added transport-constraints within vpn-svc

   o  Add ToS support in match-flow

   o  nexthop in cascaded lan as mandatory

   o  customer-specific-info deleted and moved to routing protocols

   o  customer-lan-connection modified: need prefix and CE address

   o  add choice in managing PE-CE addressing
   o  Simplifying traffic protection

   o  Refine groupings for vpn-svc

   o  Removed name in vpn-svc

   o  id in vpn-svc moved to string

   o  Rename id in vpn-svc to vpn-id

   o  Changed key of vpn-svc list to vpn-id

   o  Add DSCP support in flow definition

   o  Removed ACL from security

   o  Add FW for site and cloud access

14.16.  Changes between versions -00 and-01

   o  Creating multiple reusable groupings

   o  Added mpls leaf in vpn-svc for carrier's carrier case

   o  Modify identity single to single-site

   o  Modify site-type to site-role and also child identities.

   o  Creating OAM container under site and moved BFD in.

   o  Creating flow-definition grouping to be reused in ACL, QoS ...

   o  Simplified VPN policy.

   o  Adding multicast static group to RP mappings.

   o  Removed native-vpn and site-role from global site cfg, now managed
      within the VPN policy.

   o  Creating a separate list for site templates.

15.  References

15.1.  Normative References
   [I-D.ietf-netconf-restconf]
              Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", draft-ietf-netconf-restconf-18 (work in
              progress), October 2016.

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

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

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

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

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

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

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

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

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

   [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
              Protocol (NETCONF) Access Control Model", RFC 6536,
              DOI 10.17487/RFC6536, March 2012,
              <http://www.rfc-editor.org/info/rfc6536>.

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

15.2.

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

12.2.  Informative References

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

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              DOI 10.17487/RFC4760, January 2007,
              <http://www.rfc-editor.org/info/rfc4760>.

Acknowledgements

   Thanks to Qin Wu, Maxim Klyus, Luis Miguel Contreras, Gregory Mirsky,
   Zitao Wang, Jing Zhao, Kireeti Kompella, Eric Rosen, Aijun Wang,
   Michael Scharf, Xufeng Liu, David Ball, Lucy Yong, Jean-Philippe
   Landry, and Andrew Leu for their contributions to this document.

Contributors

   The authors would like to thank Rob Shakir for his major
   contributions to the initial modeling and use cases.

Authors' Addresses

   Stephane Litkowski
   Orange Business Services

   Email: stephane.litkowski@orange.com

   Luis Tomotaki
   Verizon

   Email: luis.tomotaki@verizon.com

   Kenichi Ogaki
   KDDI Corporation

   Email: ke-oogaki@kddi.com