GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8299

Internet Engineering Task Force (IETF) Q. Wu, Ed. Request for Comments: 8299 Huawei Obsoletes: 8049 S. Litkowski Category: Standards Track Orange ISSN: 2070-1721 L. Tomotaki

                                                               Verizon
                                                              K. Ogaki
                                                      KDDI Corporation
                                                          January 2018
             YANG Data Model for L3VPN 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 VPN service.  This document is limited
 to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364.  This
 model is intended to be instantiated at the management system to
 deliver the overall service.  It is not a configuration model to be
 used directly on network elements.  This model provides an abstracted
 view of the Layer 3 IP VPN service configuration components.  It will
 be up to the management system to take this model as input and use
 specific configuration models to configure the different network
 elements to deliver the service.  How the configuration of network
 elements is done is out of scope for this document.
 This document obsoletes RFC 8049; it replaces the unimplementable
 module in that RFC with a new module with the same name that is not
 backward compatible.  The changes are a series of small fixes to the
 YANG module and some clarifications to the text.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 https://www.rfc-editor.org/info/rfc8299.

Wu, et al. Standards Track [Page 1] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

Copyright Notice

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

Table of Contents

 1. Introduction ....................................................4
    1.1. Terminology ................................................4
    1.2. Requirements Language ......................................5
    1.3. Tree Diagrams ..............................................5
    1.4. Summary of Changes from RFC 8049 ...........................5
         1.4.1. Implementation Issues with RFC 8049 .................7
         1.4.2. Impact Assessment ...................................7
 2. Acronyms ........................................................8
 3. Definitions ....................................................10
 4. Layer 3 IP VPN Service Model ...................................10
 5. Service Data Model Usage .......................................11
 6. Design of the Data Model .......................................12
    6.1. Features and Augmentation .................................22
    6.2. VPN Service Overview ......................................22
         6.2.1. VPN Service Topology ...............................23
         6.2.2. Cloud Access .......................................26
         6.2.3. Multicast Service ..................................29
         6.2.4. Extranet VPNs ......................................30
    6.3. Site Overview .............................................32
         6.3.1. Devices and Locations ..............................33
         6.3.2. Site Network Accesses ..............................34
    6.4. Site Role .................................................36
    6.5. Site Belonging to Multiple VPNs ...........................37
         6.5.1. Site VPN Flavor ....................................37
         6.5.2. Attaching a Site to a VPN ..........................41

Wu, et al. Standards Track [Page 2] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

    6.6. Deciding Where to Connect the Site ........................47
         6.6.1. Constraint: Device .................................48
         6.6.2. Constraint/Parameter: Site Location ................48
         6.6.3. Constraint/Parameter: Access Type ..................49
         6.6.4. Constraint: Access Diversity .......................50
         6.6.5. Infeasible Access Placement ........................59
         6.6.6. Examples of Access Placement .......................60
         6.6.7. Route Distinguisher and VRF Allocation .............80
    6.7. Site Network Access Availability ..........................81
    6.8. Traffic Protection ........................................82
    6.9. Security ..................................................83
         6.9.1. Authentication .....................................83
         6.9.2. Encryption .........................................84
    6.10. Management ...............................................85
    6.11. Routing Protocols ........................................86
         6.11.1. Handling of Dual Stack ............................87
         6.11.2. LAN Directly Connected to SP Network ..............88
         6.11.3. LAN Directly Connected to SP Network with
                 Redundancy ........................................89
         6.11.4. Static Routing ....................................89
         6.11.5. RIP Routing .......................................89
         6.11.6. OSPF Routing ......................................90
         6.11.7. BGP Routing .......................................92
    6.12. Service ..................................................93
         6.12.1. Bandwidth .........................................94
         6.12.2. MTU ...............................................94
         6.12.3. QoS ...............................................94
         6.12.4. Multicast ........................................103
    6.13. Enhanced VPN Features ...................................104
         6.13.1. Carriers' Carriers ...............................104
    6.14. External ID References ..................................105
    6.15. Defining NNIs ...........................................105
         6.15.1. Defining an NNI with the Option A Flavor .........107
         6.15.2. Defining an NNI with the Option B Flavor .........111
         6.15.3. Defining an NNI with the Option C Flavor .........113
 7. Service Model Usage Example ...................................114
 8. Interaction with Other YANG Models ............................120
 9. YANG Module ...................................................125
 10. Security Considerations ......................................184
 11. IANA Considerations ..........................................185
 12. References ...................................................185
    12.1. Normative References ....................................185
    12.2. Informative References ..................................187
 Acknowledgements .................................................188
 Contributors .....................................................188
 Authors' Addresses ...............................................188

Wu, et al. Standards Track [Page 3] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

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 as input to automated
 control and configuration applications.
 This document obsoletes [RFC8049]; it creates a new module with the
 same name as the module defined in [RFC8049].  The changes from
 [RFC8049] are listed in full in Section 1.4.  They are small in
 scope, but include fixes to the module to make it possible to
 implement.
 The YANG module described in [RFC8049] cannot be implemented because
 of issues around the use of XPATH.  These issues are explained in
 Section 1.4.1.
 Section 11 of [RFC7950] describes when it is permissible to reuse a
 module name.  Section 1.4.2 provides an impact assessment in this
 context.

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

Wu, et al. Standards Track [Page 4] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 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", "NOT RECOMMENDED", "MAY", and
 "OPTIONAL" in this document are to be interpreted as described in BCP
 14 [RFC2119] [RFC8174] when, and only when, they appear in all
 capitals, as shown here.

1.3. Tree Diagrams

 A simplified graphical representation of the data model is presented
 in Section 6.
 The meanings of the symbols in these diagrams 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, 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.

1.4. Summary of Changes from RFC 8049

 This document revises and obsoletes L3VPN Service Model [RFC8049],
 drawing on insights gained from L3VPN Service Model deployments and
 on feedback from the community.  The major changes are as follows:
 o  Change type from 16-bit integer to string for the leaf id under
    "qos-classification-policy" container.
 o  Stick to using ordered-by user and remove inefficiency to map
    service model sequence number to device model sequence number.

Wu, et al. Standards Track [Page 5] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 o  Remove mandating the use of deviations and add "if-feature target-
    sites" under the leaf-list target-sites in Section 6.12.2.1 of
    [RFC8049].
 o  Change in keywords from [RFC2119] and [RFC8174] on operation of
    the management system in the third paragraph of Section 6.6,
    Section 6.6.5, and Section 7.
 o  Fix incomplete description statements.
 o  Add YANG statement to check that Stateless Address
    Autoconfiguration (SLAAC) parameters are used only for IPv6.
 o  Fix strange wording in Section 6.11.7.
 o  Change the use of the absolute paths to the use of relative paths
    in the "must" statement or "path" statement for vpn-policy-id leaf
    node, management container, location leaf node, devices container,
    location case, location-reference leaf, device case, device-
    reference leaf to make configuration is only applicable to the
    current sites.
 o  Change "must" statement to "when" statement for management
    container device container.
 o  Fix optional parameter issues by adding a default or description
    for others or make some of them mandatory.
 o  Define new grouping vpn-profile-cfg for all the identifiers
    provided by SP to the customer.  The identifiers include cloud-
    identifier, std-qos-profile, OAM profile-name, and provider-
    profile for encryption.
 o  Add in the XPATH string representation of identityrefs and remove
    unqualified name.  Change from YANG 1.0 Support to YANG 1.1
    Support.
 o  Remove "when" statement from leaf nat44-customer-address.
 o  Fixed broken example and Add mandatory element in the examples.
 o  Remove redundant parameters in the cloud access.
 o  Specify provider address and a list of start-end addresses from
    provider address for DHCP case.
 o  Add a few text to clarify what the site is in Section 6.3.

Wu, et al. Standards Track [Page 6] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 o  Add multi-filter and multiVPN per entry support for VPN policy.
 o  Modify description for svc-input-bandwidth leaf and svc-output-
    bandwidth leaf to make it consistent with the text in
    Section 6.12.1.
 o  Clarify the rational of the model in the Section 5.
 o  Add text to clarify the way to achieve Per-VPN QoS policy.

1.4.1. Implementation Issues with RFC 8049

 [RFC8049] made an initial attempt to define a YANG data model
 forL3VPN services.  After it was published it was discovered that,
 while the YANG compiled it was broken from an implementation
 perspective.  That is, it was impossible to build a functional
 implementation of the module.
 Section 1.4 provides a full list of the changes since [RFC8049].
 Some of these changes remove ambiguities from the documented YANG,
 while other changes fix the implementation issues.
 1.  Several uses of 'must' expressions in the module were broken
     badly enough that the module was not usable in the form it was
     published.  While some compilers and YANG checkers found no
     issues (most YANG tools do not attempt to parse these
     expressions), other tools that really understand the XPATH in the
     expressions refused to compile them.
     The changes needed to fix these expressions were small and local.
 2.  The second issue relates to how Access Control List (ACL) rules
     were sorted.  In [RFC8049] the English language text and the text
     in the YANG definition contradicted each other.  Furthermore, the
     model used classic ACL rule numbering notation for something that
     was semantically very different (ordered-by user) in the YANG
     thus creating the potential for misunderstanding.
 3.  Further to point 2, the ACL modeling in [RFC8049] was
     incompatible with work going on in other IETF documents such as
     [ACL-YANG].

1.4.2. Impact Assessment

 When changing the content of a YANG module, care must be taken to
 ensure that there are no interoperability issues caused by a failure
 to enable backward compatibility.

Wu, et al. Standards Track [Page 7] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 Section 11 of [RFC7950] clearly describes the circumstances under
 which it is not acceptable to maintain a module name.
    ...changes to published modules are not allowed if they have any
    potential to cause interoperability problems between a client
    using an original specification and a server using an updated
    specification.
 The module defined in this document is not backward compatible with
 that defined in [RFC8049], but it is important to understand that
 there is no possibility of an interoperability issue between the
 module defined in this document and that presented in [RFC8049]
 because that module could not be implemented for the reasons
 described in Section 1.4.1.  Thus, noting the rules set out in
 [RFC7950], it was decided to retain the module name in this document.

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: Carriers' Carriers.
 CSP: Cloud Service Provider.

Wu, et al. Standards Track [Page 8] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 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.
 NETCONF: Network Configuration Protocol.
 NNI: Network-to-Network Interface.
 OAM: Operations, Administration, and Maintenance.
 OSPF: Open Shortest Path First.
 OSS: Operations Support System.
 PE: Provider Edge.
 PIM: Protocol Independent Multicast.
 POP: Point of Presence.
 QoS: Quality of Service.
 RD: Route Distinguisher.
 RIP: Routing Information Protocol.
 RP: Rendezvous Point.
 RT: Route Target.
 SFTP: Secure FTP.
 SLA: Service Level Agreement.

Wu, et al. Standards Track [Page 9] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 SLAAC: Stateless Address 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: A CE is equipment dedicated to a
 particular customer; it is directly connected (at Layer 3) to one or
 more PE devices via attachment circuits.  A CE is usually located at
 the customer 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: A PE is equipment managed by the SP; it
 can support multiple VPNs for different customers and is directly
 connected (at Layer 3) to one or more CE devices via attachment
 circuits.  A PE is usually located at an SP point of presence (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, 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

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

Wu, et al. Standards Track [Page 10] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

5. Service Data Model Usage

                 l3vpn-svc |
                   Model   |
                           |
                    +------------------+         +-----+
                    |   Orchestration  | < --- > | OSS |
                    +------------------+         +-----+
                       |            |
               +----------------+   |
               | Config manager |   |
               +----------------+   |
                       |            |
                       | NETCONF/CLI ...
                       |            |
         +------------------------------------------------+
                              Network
                            +++++++
                            + AAA +
                            +++++++
    ++++++++   Bearer    ++++++++           ++++++++      ++++++++
    + CE A + ----------- + PE A +           + PE B + ---- + CE B +
    ++++++++  Connection ++++++++           ++++++++      ++++++++
               Site A                               Site B
 The idea of the L3 IP VPN service model is to propose an abstracted
 interface between customers and network operators to manage
 configuration of components of an L3VPN service.  The model is
 intended to be used in a mode where the network operator's system is
 the server and the customer's system is the client.  A typical
 scenario would be to use this model as an input for an orchestration
 layer that will be responsible for translating it to an orchestrated
 configuration of network elements that will be part of the service.
 The network elements can be routers but can also be servers (like
 AAA); the network's configuration is not limited to these examples.
 The configuration of network elements can be done via the CLI,
 NETCONF/RESTCONF [RFC6241] [RFC8040] coupled with YANG data models of
 a specific configuration (BGP, VRF, BFD, etc.), or some other
 technique, as preferred by the operator.
 The usage of this service model is not limited to this example; it
 can be used by any component of the management system but not
 directly by network elements.

Wu, et al. Standards Track [Page 11] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

6. Design of the Data Model

 The YANG module is divided into two main containers: "vpn-services"
 and "sites".
 The "vpn-service" list under the vpn-services container defines
 global parameters for the VPN service for a specific customer.
 A "site" is composed of at least one "site-network-access" and, in
 the case of multihoming, may have multiple site-network-access
 points.  The site-network-access attachment is done through a
 "bearer" with an "ip-connection" on top.  The bearer refers to
 properties of the attachment that are below Layer 3, while the
 connection refers to properties oriented to the Layer 3 protocol.
 The bearer may be allocated dynamically by the SP, and the customer
 may provide some constraints or parameters to drive the 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 describes the overall structure of the YANG module:

module: ietf-l3vpn-svc

  +--rw l3vpn-svc
     +--rw vpn-profiles
     |  +--rw valid-provider-identifiers
     |     +--rw cloud-identifier* [id] {cloud-access}?
     |     |  +--rw id    string
     |     +--rw encryption-profile-identifier* [id]
     |     |  +--rw id    string
     |     +--rw qos-profile-identifier* [id]
     |     |  +--rw id    string
     |     +--rw bfd-profile-identifier* [id]
     |        +--rw id    string
     +--rw 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       leafref
     |     |     +--rw (list-flavor)?
     |     |     |  +--:(permit-any)
     |     |     |  |  +--rw permit-any?            empty
     |     |     |  +--:(deny-any-except)

Wu, et al. Standards Track [Page 12] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

     |     |     |  |  +--rw permit-site*
     |     |     |  |          -> /l3vpn-svc/sites/site/site-id
     |     |     |  +--:(permit-any-except)
     |     |     |     +--rw deny-site*
     |     |     |             -> /l3vpn-svc/sites/site/site-id
     |     |     +--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)
     |     |     |              +--:(singleaddress)
     |     |     |              |  +--rw group-address?
     |     |     |              |          inet:ip-address
     |     |     |              +--:(startend)
     |     |     |                 +--rw group-start?
     |     |     |                 |       inet:ip-address
     |     |     |                 +--rw group-end?
     |     |     |                         inet:ip-address
     |     |     +--rw rp-discovery
     |     |        +--rw rp-discovery-type?   identityref
     |     |        +--rw bsr-candidates
     |     |           +--rw bsr-candidate-address*   inet:ip-address
     |     +--rw 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

Wu, et al. Standards Track [Page 13] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

           +--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
           |     |       -> ../../../locations/location/location-id
           |     +--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 filters
           |        |  +--rw filter* [type]
           |        |     +--rw type               identityref
           |        |     +--rw lan-tag*           string
           |        |     |       {lan-tag}?
           |        |     +--rw ipv4-lan-prefix*   inet:ipv4-prefix
           |        |     |       {ipv4}?
           |        |     +--rw ipv6-lan-prefix*   inet:ipv6-prefix
           |        |             {ipv6}?
           |        +--rw vpn* [vpn-id]
           |           +--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}?

Wu, et al. Standards Track [Page 14] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

           |     +--rw enabled?              boolean
           |     +--rw layer?                enumeration
           |     +--rw encryption-profile
           |        +--rw (profile)?
           |           +--:(provider-profile)
           |           |  +--rw profile-name?    leafref
           |           +--:(customer-profile)
           |              +--rw algorithm?       string
           |              +--rw (key-type)?
           |                 +--:(psk)
           |                    +--rw preshared-key?   string
           +--rw service
           |  +--rw qos {qos}?
           |  |  +--rw qos-classification-policy
           |  |  |  +--rw rule* [id]
           |  |  |     +--rw id                   string
           |  |  |     +--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
           |  |  |     |  |     |       {target-sites}?
           |  |  |     |  |     +--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)

Wu, et al. Standards Track [Page 15] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

           |  |        |  +--rw profile?   leafref
           |  |        +--:(custom)
           |  |           +--rw classes {qos-custom}?
           |  |              +--rw class* [class-id]
           |  |                 +--rw class-id      string
           |  |                 +--rw direction?    identityref
           |  |                 +--rw rate-limit?   decimal64
           |  |                 +--rw latency
           |  |                 |  +--rw (flavor)?
           |  |                 |     +--:(lowest)
           |  |                 |     |  +--rw use-lowest-latency?
           |  |                 |     |          empty
           |  |                 |     +--:(boundary)
           |  |                 |        +--rw latency-boundary?
           |  |                 |                uint16
           |  |                 +--rw jitter
           |  |                 |  +--rw (flavor)?
           |  |                 |     +--:(lowest)
           |  |                 |     |  +--rw use-lowest-jitter?
           |  |                 |     |          empty
           |  |                 |     +--:(boundary)
           |  |                 |        +--rw latency-boundary?
           |  |                 |                uint32
           |  |                 +--rw bandwidth
           |  |                    +--rw guaranteed-bw-percent
           |  |                    |       decimal64
           |  |                    +--rw end-to-end?            empty
           |  +--rw carrierscarrier {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

Wu, et al. Standards Track [Page 16] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

           |     +--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?
                 |             -> ../../../devices/device/device-id
                 +--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]
                 |              |     +--rw group-id    string
                 |              +--:(all-accesses)
                 |              |  +--rw all-other-accesses?   empty
                 |              +--:(all-groups)
                 |                 +--rw all-other-groups?     empty
                 +--rw bearer

Wu, et al. Standards Track [Page 17] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

                 |  +--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 provider-dhcp
                 |  |  |  +--rw provider-address?
                 |  |  |  |       inet:ipv4-address
                 |  |  |  +--rw prefix-length?               uint8
                 |  |  |  +--rw (address-assign)?
                 |  |  |     +--:(number)
                 |  |  |     |  +--rw number-of-dynamic-address?
                 |  |  |     |          uint16
                 |  |  |     +--:(explicit)
                 |  |  |        +--rw customer-addresses
                 |  |  |           +--rw address-group* [group-id]
                 |  |  |              +--rw group-id         string
                 |  |  |              +--rw start-address?
                 |  |  |              |       inet:ipv4-address
                 |  |  |              +--rw end-address?
                 |  |  |                      inet:ipv4-address
                 |  |  +--rw dhcp-relay
                 |  |  |  +--rw provider-address?
                 |  |  |  |       inet:ipv4-address
                 |  |  |  +--rw prefix-length?           uint8
                 |  |  |  +--rw customer-dhcp-servers
                 |  |  |     +--rw server-ip-address*
                 |  |  |             inet:ipv4-address
                 |  |  +--rw addresses
                 |  |     +--rw provider-address?   inet:ipv4-address
                 |  |     +--rw customer-address?   inet:ipv4-address
                 |  |     +--rw prefix-length?      uint8
                 |  +--rw ipv6 {ipv6}?
                 |  |  +--rw address-allocation-type?   identityref
                 |  |  +--rw provider-dhcp
                 |  |  |  +--rw provider-address?
                 |  |  |  |       inet:ipv6-address
                 |  |  |  +--rw prefix-length?               uint8
                 |  |  |  +--rw (address-assign)?
                 |  |  |     +--:(number)
                 |  |  |     |  +--rw number-of-dynamic-address?
                 |  |  |     |          uint16
                 |  |  |     +--:(explicit)
                 |  |  |        +--rw customer-addresses

Wu, et al. Standards Track [Page 18] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

                 |  |  |           +--rw address-group* [group-id]
                 |  |  |              +--rw group-id         string
                 |  |  |              +--rw start-address?
                 |  |  |              |       inet:ipv6-address
                 |  |  |              +--rw end-address?
                 |  |  |                      inet:ipv6-address
                 |  |  +--rw dhcp-relay
                 |  |  |  +--rw provider-address?
                 |  |  |  |       inet:ipv6-address
                 |  |  |  +--rw prefix-length?           uint8
                 |  |  |  +--rw customer-dhcp-servers
                 |  |  |     +--rw server-ip-address*
                 |  |  |             inet:ipv6-address
                 |  |  +--rw addresses
                 |  |     +--rw provider-address?   inet:ipv6-address
                 |  |     +--rw customer-address?   inet:ipv6-address
                 |  |     +--rw prefix-length?      uint8
                 |  +--rw oam
                 |     +--rw bfd {bfd}?
                 |        +--rw enabled?        boolean
                 |        +--rw (holdtime)?
                 |           +--:(fixed)
                 |           |  +--rw fixed-value?    uint32
                 |           +--:(profile)
                 |              +--rw profile-name?   leafref
                 +--rw security
                 |  +--rw authentication
                 |  +--rw encryption {encryption}?
                 |     +--rw enabled?              boolean
                 |     +--rw layer?                enumeration
                 |     +--rw encryption-profile
                 |        +--rw (profile)?
                 |           +--:(provider-profile)
                 |           |  +--rw profile-name?    leafref
                 |           +--:(customer-profile)
                 |              +--rw algorithm?       string
                 |              +--rw (key-type)?
                 |                 +--:(psk)
                 |                    +--rw preshared-key?   string
                 +--rw service
                 |  +--rw svc-input-bandwidth     uint64
                 |  +--rw svc-output-bandwidth    uint64
                 |  +--rw svc-mtu                 uint16
                 |  +--rw qos {qos}?
                 |  |  +--rw qos-classification-policy
                 |  |  |  +--rw rule* [id]
                 |  |  |     +--rw id                   string
                 |  |  |     +--rw (match-type)?

Wu, et al. Standards Track [Page 19] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

                 |  |  |     |  +--:(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
                 |  |  |     |  |     |       {target-sites}?
                 |  |  |     |  |     +--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?   leafref
                 |  |        +--:(custom)
                 |  |           +--rw classes {qos-custom}?
                 |  |              +--rw class* [class-id]
                 |  |                 +--rw class-id      string
                 |  |                 +--rw direction?    identityref
                 |  |                 +--rw rate-limit?   decimal64
                 |  |                 +--rw latency
                 |  |                 |  +-rw (flavor)?
                 |  |                 |    +--:(lowest)
                 |  |                 |    |  +-rw use-lowest-latency?

Wu, et al. Standards Track [Page 20] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

                 |  |                 |    |          empty
                 |  |                 |    +--:(boundary)
                 |  |                 |       +-rw latency-boundary?
                 |  |                 |                uint16
                 |  |                 +--rw jitter
                 |  |                 |  +-rw (flavor)?
                 |  |                 |    +--:(lowest)
                 |  |                 |    |  +--rw use-lowest-jitter?
                 |  |                 |    |          empty
                 |  |                 |    +--:(boundary)
                 |  |                 |       +--rw latency-boundary?
                 |  |                 |                uint32
                 |  |                 +--rw bandwidth
                 |  |                    +--rw guaranteed-bw-percent
                 |  |                    |       decimal64
                 |  |                    +--rw end-to-end?
                 |  |                            empty
                 |  +--rw carrierscarrier {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}?

Wu, et al. Standards Track [Page 21] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

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

 The model defined in this document implements many features that
 allow implementations to be modular.  As an example, an
 implementation may support only IPv4 VPNs (IPv4 feature), 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 also defines some features for options that are
 more advanced, such as support for extranet VPNs (Section 6.2.4),
 site diversity (Section 6.6), and QoS (Section 6.12.3).
 In addition, as for any YANG data model, this service model can be
 augmented to implement new behaviors or specific features.  For
 example, this model uses different options for IP address
 assignments; if those options do not fulfill all requirements, new
 options can be added through augmentation.

6.2. VPN Service Overview

 A vpn-service list item contains generic information about the VPN
 service.  The "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 reference to the customer.  This identifier
 is purely internal to the organization responsible for the VPN
 service.

Wu, et al. Standards Track [Page 22] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

6.2.1. VPN Service Topology

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

6.2.1.1. Route Target Allocation

 A Layer 3 PE-based VPN is built using route targets (RTs) as
 described in [RFC4364].  The management system is expected to
 automatically allocate a set of RTs upon receiving a VPN service
 creation request.  How the management system allocates RTs is out of
 scope for this document, but multiple ways could be envisaged, as
 described below.
                                  Management system
                   <------------------------------------------------->
                                               Request RT
                    +-----------------------+  Topo a2a   +----------+
         RESTCONF   |                       |  ----->     |          |
 User ------------- | Service Orchestration |             | Network  |
         l3vpn-svc  |                       |  <-----     |   OSS    |
           Model    +-----------------------+   Response  +----------+
                                                RT1, RT2
 In the example above, a service orchestration, owning the
 instantiation of this service model, requests RTs to the network OSS.
 Based on the requested VPN service topology, the network OSS replies
 with one or multiple RTs.  The interface between this service
 orchestration and the network OSS is out of scope for this document.
                              +---------------------------+
                   RESTCONF   |                           |
           User ------------- |   Service Orchestration   |
                   l3vpn-svc  |                           |
                     Model    |                           |
                              |  RT pool: 10:1->10:10000  |
                              |  RT 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 RTs
 (specified by the SP) that can be allocated.  Based on the requested
 VPN service topology, it will allocate one or multiple RTs from the
 pool.

Wu, et al. Standards Track [Page 23] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

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

6.2.1.2. Any-to-Any

    +------------------------------------------------------------+
    |  VPN1_Site1 ------ PE1               PE2 ------ VPN1_Site2 |
    |                                                            |
    |  VPN1_Site3 ------ PE3               PE4 ------ VPN1_Site4 |
    +------------------------------------------------------------+
                    Any-to-Any VPN Service Topology
 In the any-to-any VPN service topology, all VPN sites can communicate
 with each other without any restrictions.  The management system that
 receives an any-to-any IP VPN service request through this model is
 expected to assign and then configure the VRF and RTs on the
 appropriate PEs.  In the any-to-any case, a single RT is generally
 required, and every VRF imports and exports this RT.

6.2.1.3. Hub and Spoke

    +-------------------------------------------------------------+
    |   Hub_Site1 ------ PE1               PE2 ------ Spoke_Site1 |
    |                          +----------------------------------+
    |                          |
    |                          +----------------------------------+
    |   Hub_Site2 ------ PE3               PE4 ------ Spoke_Site2 |
    +-------------------------------------------------------------+
                    Hub-and-Spoke VPN Service Topology
 In the Hub-and-Spoke VPN service topology, all Spoke sites can
 communicate only with Hub sites but not with each other, and Hubs can
 also communicate with each other.  The management system that owns an
 any-to-any IP VPN service request through this model is expected to
 assign and then configure the VRF and RTs on the appropriate PEs.  In
 the Hub-and-Spoke case, two RTs are generally required (one RT for
 Hub routes and one RT for Spoke routes).  A Hub VRF that connects Hub
 sites will export Hub routes with the Hub RT and will import Spoke
 routes through the Spoke RT.  It will also import the Hub RT to allow
 Hub-to-Hub communication.  A Spoke VRF that connects Spoke sites will
 export Spoke routes with the Spoke RT and will import Hub routes
 through the Hub RT.

Wu, et al. Standards Track [Page 24] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 The management system MUST take into account constraints on Hub-and-
 Spoke connections.  For example, if a management system decides to
 mesh a Spoke site and a Hub site on the same PE, it needs to mesh
 connections in different VRFs, as shown in the figure below.
                  Hub_Site ------- (VRF_Hub)  PE1
                                             (VRF_Spoke)
                                               /  |
               Spoke_Site1 -------------------+   |
                                                  |
               Spoke_Site2 -----------------------+

6.2.1.4. Hub and Spoke Disjoint

    +-------------------------------------------------------------+
    |   Hub_Site1 ------ PE1               PE2 ------ Spoke_Site1 |
    +--------------------------+  +-------------------------------+
                               |  |
    +--------------------------+  +-------------------------------+
    |   Hub_Site2 ------ PE3               PE4 ------ Spoke_Site2 |
    +-------------------------------------------------------------+
              Hub and Spoke Disjoint VPN Service Topology
 In the Hub and Spoke disjoint VPN service topology, all Spoke sites
 can communicate only with Hub sites but not with each other, and Hubs
 cannot communicate with each other.  The management system that owns
 an any-to-any IP VPN service request through this model is expected
 to assign and then configure the VRF and RTs on the appropriate PEs.
 In the Hub-and-Spoke case, two RTs are required (one RT for Hub
 routes and one RT for Spoke routes).  A Hub VRF that connects Hub
 sites will export Hub routes with the Hub RT and will import Spoke
 routes through the Spoke RT.  A Spoke VRF that connects Spoke sites
 will export Spoke routes with the Spoke RT and will import Hub routes
 through the Hub RT.
 The management system MUST take into account constraints on Hub-and-
 Spoke connections, as in the previous case.
 Hub and Spoke disjoint can also be seen as multiple Hub-and-Spoke
 VPNs (one per Hub) that share a common set of Spoke sites.

Wu, et al. Standards Track [Page 25] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

6.2.2. Cloud Access

 The proposed model provides cloud access configuration via the
 "cloud-accesses" container.  The usage of cloud-access is targeted
 for the public cloud.  An Internet access can also be considered a
 public cloud access service.  The cloud-accesses container provides
 parameters for network address translation and authorization rules.
 A private cloud access may be addressed through 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 address translation (NAT44) is the only
 supported option, but other options can be added through
 augmentation.  If IP source address translation is required to access
 the cloud, the "enabled" leaf MUST be set to true in the "nat44"
 container.  An IP address may be provided in the "customer-address"
 leaf if the customer is providing the IP address to be used for the
 cloud access.  If the SP is providing this address, "customer-
 address" is not necessary, as it can be picked from a pool of SPs.
 By default, all sites in the IP VPN MUST be authorized to access the
 cloud.  If restrictions are required, a user MAY configure the
 "permit-site" or "deny-site" leaf-list.  The permit-site leaf-list
 defines the list of sites authorized for cloud access.  The deny-site
 leaf-list defines the list of sites denied for cloud access.  The
 model supports both "deny-any-except" and "permit-any-except"
 authorization.
 How the restrictions will be configured on network elements is out of
 scope for this document.

Wu, et al. Standards Track [Page 26] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

                     IP VPN
           ++++++++++++++++++++++++++++++++     ++++++++++++
           +             Site 3           + --- +  Cloud 1 +
           + Site 1                       +     ++++++++++++
           +                              +
           + Site 2                       + --- ++++++++++++
           +                              +     + Internet +
           +            Site 4            +     ++++++++++++
           ++++++++++++++++++++++++++++++++
                        |
                   +++++++++++
                   + Cloud 2 +
                   +++++++++++
 In the example above, we 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 will be configured, as
 all sites are required to access the Internet.  The "address-
 translation/nat44/enabled" leaf will be set to true.
    <?xml version="1.0"?>
    <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
      <vpn-services>
        <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>
      </vpn-services>
    </l3vpn-svc>

Wu, et al. Standards Track [Page 27] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 If Site 1 and Site 2 require access to Cloud 1, a new cloud-access
 pointing to the cloud identifier of Cloud 1 will be created.  The
 permit-site leaf-list will be filled with a reference to Site 1 and
 Site 2.
    <?xml version="1.0"?>
    <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
      <vpn-services>
        <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-accesses>
        </vpn-service>
      </vpn-services>
    </l3vpn-svc>
 If all sites except Site 1 require access to Cloud 2, a new cloud-
 access pointing to the cloud identifier of Cloud 2 will be created.
 The deny-site leaf-list will be filled with a reference to Site 1.
    <?xml version="1.0"?>
    <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
      <vpn-services>
        <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>
      </vpn-services>
    </l3vpn-svc>
 A service with more than one cloud access is functionally identical
 to multiple services each with a single cloud access, where the sites
 that belong to each service in the latter case correspond with the
 authorized sites for each cloud access in the former case.  However,
 defining a single service with multiple cloud accesses may be
 operationally simpler.

Wu, et al. Standards Track [Page 28] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

6.2.3. Multicast Service

 Multicast in IP VPNs is described in [RFC6513].
 If multicast support is required for an IP VPN, some global multicast
 parameters are required as input for the service request.
 Users of this model will need to provide the flavors of trees that
 will be used by customers within the IP VPN (customer tree).  The
 proposed model supports bidirectional, shared, and source-based trees
 (and can be augmented).  Multiple flavors of 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)              |
                              |                 |
                               \_______________/
 When an ASM flavor is requested, this model requires that the "rp"
 and "rp-discovery" parameters be filled.  Multiple RP-to-group
 mappings can be created using the "rp-group-mappings" container.  For
 each mapping, the SP can manage the RP service by setting the
 "provider-managed/enabled" leaf to true.  In the case of a provider-
 managed RP, the user can request RP redundancy and/or optimal traffic
 delivery.  Those parameters will help the SP select the appropriate
 technology or architecture to fulfill the customer service
 requirement: for instance, in the case of a request for optimal
 traffic delivery, an SP may use Anycast-RP or RP-tree-to-SPT
 switchover architectures.

Wu, et al. Standards Track [Page 29] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 In the case of a customer-managed RP, the RP address must be filled
 in the RP-to-group mappings using the "rp-address" leaf.  This leaf
 is not needed for a provider-managed RP.
 Users can define a specific mechanism for RP discovery, such as the
 "auto-rp", "static-rp", or "bsr-rp" modes.  By default, the model
 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-managed and customer-managed RPs.  In the
 case of a provider-managed RP, if the user wants to use "bsr-rp" as a
 discovery protocol, an SP should consider the provider-managed
 "rp-group-mappings" for the "bsr-rp" configuration.  The SP will then
 configure its selected RPs to be "bsr-rp-candidates".  In the case of
 a customer-managed RP and a "bsr-rp" discovery mechanism, the
 "rp-address" provided will be the bsr-rp candidate.

6.2.4. Extranet VPNs

 There are some cases where a particular VPN needs access to resources
 (servers, hosts, etc.) that are external.  Those resources may be
 located in another VPN.
                +-----------+           +-----------+
               /             \         /             \
    Site A -- |    VPN A      |  ---  |    VPN B      | --- 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 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 access to all resources in another VPN
 (VPN B).  The model provides an easy way to set up this connection
 using the "extranet-vpns" container.
 The extranet-vpns container defines a list of VPNs a particular VPN
 wants to access.  The extranet-vpns container must be used on
 customer VPNs accessing extranet resources in another VPN.  In the
 figure above, in order to 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.  There is no service configuration
 requirement on VPN B.

Wu, et al. Standards Track [Page 30] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 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 VPN B resources through an
 extranet connection.  A Spoke role is required for VPN A sites, as
 sites from VPN A must not be able to communicate with each other
 through the extranet VPN connection.
    <?xml version="1.0"?>
    <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
      <vpn-services>
        <vpn-service>
          <vpn-id>VPNB</vpn-id>
          <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>
              <local-sites-role>spoke-role</local-sites-role>
            </extranet-vpn>
          </extranet-vpns>
        </vpn-service>
      </vpn-services>
    </l3vpn-svc>
 This model does not define how the extranet configuration will be
 achieved.
 Any VPN interconnection scenario that is more complex (e.g., only
 certain parts of sites on VPN A accessing only certain parts of sites
 on VPN B) needs to be achieved using a VPN attachment as defined in
 Section 6.5.2, and especially a VPN policy as defined in
 Section 6.5.2.2.

Wu, et al. Standards Track [Page 31] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

6.3. Site Overview

 A site represents a connection of a customer office to one or more
 VPN services.  Each site is associated with one or more locations.
                                                  +-------------+
                                                 /               \
   +------------------+                   +-----|      VPN1       |
   |                  |                   |      \               /
   |  New York Office |------ (site) -----+       +-------------+
   |                  |                   |       +-------------+
   +------------------+                   |      /               \
                                          +-----|      VPN2       |
                                                 \               /
                                                  +-------------+
 A site has several characteristics:
 o  Unique identifier (site-id): uniquely identifies the site within
    the overall network infrastructure.  The identifier is a string
    that allows any encoding for the local administration of the VPN
    service.
 o  Locations (locations): site location information that allows easy
    retrieval of information from the nearest available resources.  A
    site may be composed of multiple locations.  Alternatively, two or
    more sites can be associated with the same location, by
    referencing the same location ID.
 o  Devices (devices): allows the customer to request one or more
    customer premises equipment entities from the SP for a particular
    site.
 o  Management (management): defines the type of management for the
    site -- for example, co-managed, customer-managed, or provider-
    managed.  See Section 6.10.
 o  Site network accesses (site-network-accesses): defines the list of
    network accesses associated with the sites, and their properties
    -- especially bearer, connection, and service parameters.
 A site-network-access represents an IP logical connection of a site.
 A site may have multiple site-network-accesses.

Wu, et al. Standards Track [Page 32] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

       +------------------+             Site
       |                  |-----------------------------------
       |                  |****** (site-network-access#1) ******
       |  New York Office |
       |                  |****** (site-network-access#2) ******
       |                  |-----------------------------------
       +------------------+
 Multiple site-network-accesses are used, for instance, in the case of
 multihoming.  Some other meshing cases may also include multiple
 site-network-accesses.
 The site configuration is viewed as a global entity; we assume that
 it is mostly 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

 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 a multi-location site is 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 premises equipment entities (CEs)
 from the 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 location.  This would help

Wu, et al. Standards Track [Page 33] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 the SP send the device to the appropriate postal address.  In a
 multi-location site, a customer may, for 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, etc.

6.3.2. Site Network Accesses

 As mentioned earlier, a site may be multihomed.  Each IP network
 access for a site is defined in the "site-network-accesses"
 container.  The 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's availability policy.  The
    availability parameters are defined in Section 6.7.
 The site-network-access has a specific type (site-network-access-
 type).  This document defines two types:
 o  point-to-point: describes a point-to-point connection between the
    SP and the customer.
 o  multipoint: describes a multipoint connection between the SP and
    the customer.
 The type of site-network-access may have an impact on the parameters
 offered to the customer, e.g., an SP may not offer encryption for
 multipoint accesses.  It is up to the provider to decide what
 parameter is supported for point-to-point and/or multipoint accesses;
 this topic is out of scope for this document.  Some containers
 proposed in the model may require extensions in order to work
 properly for multipoint accesses.

6.3.2.1. Bearer

 The bearer container defines the requirements for the site attachment
 to the provider network that are below Layer 3.
 The bearer parameters will help determine the access media to be
 used.  This is further described in Section 6.6.3.

Wu, et al. Standards Track [Page 34] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

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 PE-CE addressing or CE-to-customer-LAN addressing.  In any
 case, it describes the responsibility boundary between the provider
 and the customer.  For a customer-managed site, it refers to the
 PE-CE connection.  For a provider-managed site, it refers to the
 CE-to-LAN connection.

6.3.2.2.1. IP Addressing

 An IP subnet can be configured for either IPv4 or IPv6 Layer 3
 protocols.  For a dual-stack connection, two subnets will be
 provided, one for each address family.
 The "address-allocation-type" determines how the address allocation
 needs to be done.  The current model defines five ways to perform IP
 address allocation:
 o  provider-dhcp: The provider will provide DHCP service for customer
    equipment; this is applicable to either the "IPv4" container or
    the "IPv6" container.
 o  provider-dhcp-relay: The provider will provide DHCP relay service
    for customer equipment; this is applicable to both IPv4 and IPv6
    addressing.  The customer needs to populate the DHCP server list
    to be used.
 o  static-address: Addresses will be assigned manually; this is
    applicable to both IPv4 and IPv6 addressing.
 o  slaac: This parameter enables stateless address autoconfiguration
    [RFC4862].  This is applicable to IPv6 only.
 o  provider-dhcp-slaac: The provider will provide DHCP service for
    customer equipment, as well as stateless address
    autoconfiguration.  This is applicable to IPv6 only.
 In the dynamic addressing mechanism, the SP is expected to provide at
 least the IP address, prefix length, and default gateway information.
 In the case of multiple site-network-access points belonging to the
 same VPN, address space allocated for one site-network-access should
 not conflict with one allocated for other site-network-accesses.

Wu, et al. Standards Track [Page 35] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

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 via
 augmentation.  The provider can propose some profiles to the
 customer, depending on the service level the customer wants to
 achieve.  Profile names must be communicated to the customer.  This
 communication is out of scope for this document.  Some fixed values
 for the holdtime period may also be imposed by the customer if the
 provider allows the customer this function.
 The "oam" container can easily be augmented by other mechanisms; in
 particular, work done by the LIME Working Group
 (https://datatracker.ietf.org/wg/lime/charter/) may be reused in
 applicable scenarios.

6.3.2.3. Inheritance of Parameters Defined at Site Level and Site

        Network Access Level
 Some parameters can be configured at both the site level and the
 site-network-access level, e.g., routing, services, 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 parameter MUST override the site-level
 parameter.  Those parameters will be described later in this
 document.
 In terms of provisioning impact, it will be up to the implementation
 to decide on the appropriate behavior when modifying existing
 configurations.  But the SP will need to communicate to the user
 about the impact of using inheritance.  For example, if we consider
 that a site has already provisioned three site-network-accesses, what
 will happen if a customer changes a service parameter at the site
 level?  An implementation of this model may update the service
 parameters of all already-provisioned site-network-accesses (with
 potential impact on live traffic), or it may take into account this
 new parameter only for the new sites.

6.4. Site Role

 A VPN has a particular service 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, which will be "any-to-any-role".

Wu, et al. Standards Track [Page 36] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

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

6.5. Site Belonging to Multiple VPNs

6.5.1. Site VPN Flavor

 A site may be part of one or multiple VPNs.  The "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 site belongs to only one VPN.
 o  site-vpn-flavor-multi: The site belongs to multiple VPNs, and all
    the logical accesses of the sites belong to the same set of VPNs.
 o  site-vpn-flavor-sub: 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 site represents an option A NNI.

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

 The figure below describes a single VPN attachment.  The site
 connects to only one VPN.
                                                       +--------+
    +------------------+             Site             /          \
    |                  |-----------------------------|            |
    |                  |***(site-network-access#1)***|    VPN1    |
    |  New York Office |                             |            |
    |                  |***(site-network-access#2)***|            |
    |                  |-----------------------------|            |
    +------------------+                              \          /
                                                       +--------+

Wu, et al. Standards Track [Page 37] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

6.5.1.2. 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
 logical accesses are using the same VPN attachment rules, and both
 are connected to VPN A and VPN B.
 Reaching VPN A or VPN B from the New York office will be done via
 destination-based routing.  Having the same destination reachable
 from the two VPNs may cause routing troubles.  The customer
 administration's role in this case would be to ensure the appropriate
 mapping of its prefixes in each VPN.

6.5.1.3. SubVPN Attachment: site-vpn-flavor-sub

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

Wu, et al. Standards Track [Page 38] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

  +------------------+         Site                      +--------+
  |                  |----------------------------------/          \
  |                  |****(site-network-access#1)******|    VPN B   |
  |  New York Office |                                  \          /
  |                  |                                   +--------+
  |                  |                                   +--------+
  |                  |                                  /          \
  |                  |****(site-network-access#2)******|    VPN A   |
  |                  |                                  \          /
  |                  |                                   +--------+
  |                  |-----------------------------------
  +------------------+
 A multiVPN can be implemented in addition to a subVPN; as a
 consequence, each site-network-access can access multiple VPNs.  In
 the example below, site-network-access#1 is mapped to VPN B and VPN
 C, while site-network-access#2 is mapped to VPN A and VPN D.
 +-----------------+         Site                    +------+
 |                 |--------------------------------/       +-----+
 |                 |****(site-network-access#1)****| VPN B /       \
 | New York Office |                                \     |  VPN C  |
 |                 |                                 +-----\       /
 |                 |                                        +-----+
 |                 |
 |                 |                                 +-------+
 |                 |                                /        +-----+
 |                 |****(site-network-access#2)****| VPN A  /       \
 |                 |                                \      | VPN D   |
 |                 |                                 +------\       /
 |                 |---------------------------------        +-----+
 +-----------------+
 Multihoming is also possible with subVPNs; in this case, site-
 network-accesses are grouped, and a particular group will have access
 to the same set of VPNs.  In the example below, site-network-access#1
 and site-network-access#2 are part of the same group (multihomed
 together) and are mapped to VPN B and VPN C; in addition, site-
 network-access#3 and site-network-access#4 are part of the same group
 (multihomed together) and are mapped to VPN A and VPN D.

Wu, et al. Standards Track [Page 39] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 +-----------------+         Site                     +------+
 |                 |---------------------------------/       +-----+
 |                 |****(site-network-access#1)*****| VPN B /       \
 | New York Office |****(site-network-access#2)***** \     |  VPN C  |
 |                 |                                  +-----\       /
 |                 |                                         +-----+
 |                 |
 |                 |                                  +------+
 |                 |                                 /       +-----+
 |                 |****(site-network-access#3)*****| VPN A /       \
 |                 |****(site-network-access#4)***** \     | VPN D   |
 |                 |                                  +-----\       /
 |                 |----------------------------------       +-----+
 +-----------------+
 In terms of service configuration, a subVPN can be achieved by
 requesting that the site-network-access use the same bearer (see
 Section 6.6.4 for more details).

6.5.1.4. NNI: site-vpn-flavor-nni

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

Wu, et al. Standards Track [Page 40] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

         SP A                                             SP B
    -------------------                         -------------------
   /                   \                       /                   \
  |                     |                     |                     |
  |                 ++++++++ Inter-AS link ++++++++                 |
  |                 +      +_______________+      +                 |
  |                 +  (VRF1)---(VPN1)----(VRF1)  +                 |
  |                 + ASBR +               + ASBR +                 |
  |                 +  (VRF2)---(VPN2)----(VRF2)  +                 |
  |                 +      +_______________+      +                 |
  |                 ++++++++               ++++++++                 |
  |                     |                     |                     |
  |                     |                     |                     |
  |                     |                     |                     |
  |                 ++++++++ Inter-AS link ++++++++                 |
  |                 +      +_______________+      +                 |
  |                 +  (VRF1)---(VPN1)----(VRF1)  +                 |
  |                 + ASBR +               + ASBR +                 |
  |                 +  (VRF2)---(VPN2)----(VRF2)  +                 |
  |                 +      +_______________+      +                 |
  |                 ++++++++               ++++++++                 |
  |                     |                     |                     |
  |                     |                     |                     |
   \                   /                       \                   /
    -------------------                         -------------------
 The figure above describes an option A NNI scenario that can be
 modeled using the sites container.  In order to connect its customer
 VPNs (VPN1 and VPN2) in SP B, SP A may request the creation of some
 site-network-accesses to SP B.  The 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 to a VPN

 Due to the multiple site-vpn flavors, the attachment of a site to an
 IP VPN is done at the site-network-access (logical access) level
 through the "vpn-attachment" container.  The vpn-attachment container
 is mandatory.  The model provides two ways to attach a site to a VPN:
 o  By referencing the target VPN directly.
 o  By referencing a VPN policy for attachments that are more complex.
 A choice is implemented to allow the user to choose the flavor that
 provides the best fit.

Wu, et al. Standards Track [Page 41] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

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

<?xml version="1.0"?> <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">

<vpn-services>
 <vpn-service>
  <vpn-id>VPNA</vpn-id>
 </vpn-service>
 <vpn-service>
  <vpn-id>VPNB</vpn-id>
 </vpn-service>
</vpn-services>
<sites>
 <site>
  <site-id>SITE1</site-id>
  <locations>
   <location>
    <location-id>L1</location-id>
   </location>
  </locations>
  <management>
   <type>customer-managed</type>
  </management>
  <security>
   <encryption>
    <layer>layer3</layer>
   </encryption>
  </security>
  <site-network-accesses>
   <site-network-access>
    <site-network-access-id>LA1</site-network-access-id>
    <ip-connection>
     <ipv4>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv4>
     <ipv6>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv6>
    </ip-connection>
    <service>
     <svc-mtu>1514</svc-mtu>

Wu, et al. Standards Track [Page 42] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

     <svc-input-bandwidth>10000000</svc-input-bandwidth>
     <svc-output-bandwidth>10000000</svc-output-bandwidth>
    </service>
    <security>
     <encryption>
      <layer>layer3</layer>
     </encryption>
    </security>
    <location-reference>L1</location-reference>
    <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>
    <ip-connection>
     <ipv4>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv4>
     <ipv6>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv6>
    </ip-connection>
    <service>
     <svc-mtu>1514</svc-mtu>
     <svc-input-bandwidth>10000000</svc-input-bandwidth>
     <svc-output-bandwidth>10000000</svc-output-bandwidth>
    </service>
    <security>
     <encryption>
      <layer>layer3</layer>
     </encryption>
    </security>
    <location-reference>L1</location-reference>
    <vpn-attachment>
     <vpn-id>VPNB</vpn-id>
     <site-role>spoke-role</site-role>
    </vpn-attachment>
   </site-network-access>
  </site-network-accesses>
 </site>
</sites>

</l3vpn-svc>

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

Wu, et al. Standards Track [Page 43] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

6.5.2.2. VPN Policy

 The "vpn-policy" list helps 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 in VPN2 and an any-to-any role in VPN3.  We can
 express such a multiVPN scenario with the following XML snippet:

<?xml version="1.0"?> <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">

<vpn-services>
 <vpn-service>
  <vpn-id>VPN2</vpn-id>
 </vpn-service>
 <vpn-service>
  <vpn-id>VPN3</vpn-id>
 </vpn-service>
</vpn-services>
<sites>
 <site>
  <site-id>Site5</site-id>
  <devices>

Wu, et al. Standards Track [Page 44] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

   <device>
    <device-id>D1</device-id>
   </device>
  </devices>
  <management>
   <type>provider-managed</type>
  </management>
  <security>
   <encryption>
    <layer>layer3</layer>
   </encryption>
  </security>
  <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>
    <device-reference>D1</device-reference>
    <ip-connection>
     <ipv4>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv4>
     <ipv6>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv6>
    </ip-connection>
    <service>
     <svc-mtu>1514</svc-mtu>
     <svc-input-bandwidth>10000000</svc-input-bandwidth>
     <svc-output-bandwidth>10000000</svc-output-bandwidth>
    </service>

Wu, et al. Standards Track [Page 45] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

    <security>
     <encryption>
      <layer>layer3</layer>
     </encryption>
    </security>
    <vpn-attachment>
     <vpn-policy-id>POLICY1</vpn-policy-id>
    </vpn-attachment>
   </site-network-access>
  </site-network-accesses>
 </site>
</sites>

</l3vpn-svc>

 Now, if a more-granular VPN attachment is necessary, filtering can be
 used.  For example, if only LAN1 from Site5 must be attached to VPN2
 as a Hub and only LAN2 must be attached to VPN3, the following XML
 snippet can be used:
    <?xml version="1.0"?>
    <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
      <vpn-services>
        <vpn-service>
          <vpn-id>VPN2</vpn-id>
        </vpn-service>
        <vpn-service>
          <vpn-id>VPN3</vpn-id>
        </vpn-service>
      </vpn-services>
      <sites>
        <site>
          <site-id>Site5</site-id>
          <vpn-policies>
            <vpn-policy>
              <vpn-policy-id>POLICY1</vpn-policy-id>
              <entries>
                <id>ENTRY1</id>
                <filters>
                  <filter>
                    <type>lan</type>
                    <lan-tag>LAN1</lan-tag>
                  </filter>
                </filters>
                <vpn>
                  <vpn-id>VPN2</vpn-id>
                  <site-role>hub-role</site-role>
                </vpn>
              </entries>

Wu, et al. Standards Track [Page 46] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

              <entries>
                <id>ENTRY2</id>
                <filters>
                  <filter>
                    <type>lan</type>
                    <lan-tag>LAN2</lan-tag>
                  </filter>
                </filters>
                <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>
      </sites>
    </l3vpn-svc>

6.6. Deciding Where to Connect the Site

 The management system will have to determine where to connect each
 site-network-access of a particular site to the provider network
 (e.g., PE, aggregation switch).
 The current model defines parameters and constraints that can
 influence the meshing of the site-network-access.
 The management system MUST honor all customer constraints, or if a
 constraint is too strict and cannot be fulfilled, the management
 system MUST NOT provision the site and MUST provide information to
 the user about which constraints could not be fulfilled.  How the
 information is provided is out of scope for this document.  Whether
 or not to relax the constraint would then be left up to the user.
 Parameters such as site location (see Section 6.6.2) and access type
 are just hints (see Section 6.6.3) for the management system for
 service placement.

Wu, et al. Standards Track [Page 47] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

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

6.6.1. Constraint: Device

 In the case of provider management or co-management, one or more
 devices have been ordered by the customer to a particular already-
 configured location.  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, site-network-access#1 is associated with CE1 in
 the service request.  The SP must ensure the provisioning of this
 connection.

6.6.2. Constraint/Parameter: Site Location

 The location information provided in this model MAY be used by a
 management system to determine the target PE to mesh the site (SP
 side).  A particular location must be associated with each site
 network access when configuring it.  The SP MUST honor the
 termination of the access on the location associated with the site
 network access (customer side).  The "country-code" in the site
 location SHOULD be expressed as an ISO ALPHA-2 code.
 The site-network-access location is determined by the "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 with a
 particular location, in such a case the location information is
 retrieved from the device location.  In the case of a customer-

Wu, et al. Standards Track [Page 48] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 managed site, the user is expected to configure a "location-
 reference" (location case); this provides a reference to an existing
 configured location and will help with placement.
                                      POP#1 (New York)
                                   +---------+
                                   |   PE1   |
              Site #1 ---...       |   PE2   |
             (Atlantic City)       |   PE3   |
                                   +---------+
                                      POP#2 (Washington)
                                   +---------+
                                   |   PE4   |
                                   |   PE5   |
                                   |   PE6   |
                                   +---------+
                                      POP#3 (Philadelphia)
                                   +---------+
                                   |   PE7   |
              Site #2 CE#1---...   |   PE8   |
             (Reston)              |   PE9   |
                                   +---------+
 In the example above, Site #1 is a customer-managed site with a
 location L1, while Site #2 is a provider-managed site for which a CE
 (CE#1) was ordered.  Site #2 is configured with L2 as its location.
 When configuring a site-network-access for Site #1, the user will
 need to reference location L1 so that the management system will know
 that the access will need to terminate on this location.  Then, for
 distance reasons, this management system may mesh Site #1 on a PE in
 the Philadelphia POP.  It may also take into account resources
 available on PEs to determine the exact target PE (e.g., least
 loaded).  For Site #2, the user is expected to configure the site-
 network-access with a device-reference to 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 placement of the SP side of
 the access connection, in the case of the nearest PE used, it may
 mesh Site #2 on the Washington POP.

6.6.3. Constraint/Parameter: Access Type

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

Wu, et al. Standards Track [Page 49] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 The bearer container information SHOULD be the first piece of
 information considered when making this decision:
 o  The "requested-type" parameter provides information about the
    media type that the customer would like to use.  If the "strict"
    leaf is equal to "true", this MUST be considered a strict
    constraint so that the management system cannot connect the site
    with another media type.  If the "strict" leaf is equal to "false"
    (default) and if the requested media type cannot be fulfilled, the
    management system can select another media type.  The supported
    media types SHOULD be communicated by the SP to the customer via a
    mechanism that is out of scope for this document.
 o  The "always-on" leaf defines a strict constraint: if set to true,
    the management system MUST elect a media type that is "always-on"
    (e.g., this means no dial access type).
 o  The "bearer-reference" parameter is used in cases where the
    customer has already ordered a network connection to the SP apart
    from the IP VPN site and wants to reuse this connection.  The
    string used is an internal reference from the SP and describes the
    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 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 SP may have provided the bearer
    reference that can be used for provisioning services on top.
 Any other internal parameters from the SP can also be used.  The
 management system MAY use other parameters, such as the requested
 "svc-input-bandwidth" and "svc-output-bandwidth", to help decide
 which access type to use.

6.6.4. Constraint: 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 constraints, but allocation of a unique bearer per
 site-network-access is expected.
 In order to help with the different placement scenarios, a site-
 network-access may be tagged using one or multiple group identifiers.
 The group identifier is a string, so it can accommodate both explicit
 naming of a group of sites (e.g., "multihomed-set1" or "subVPN") and
 the use of a numbered identifier (e.g., 12345678).  The meaning of
 each group-id is local to each customer 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

Wu, et al. Standards Track [Page 50] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 site level; as a consequence, all site-network-accesses under the
 site MUST inherit the group-ids of the site they belong to.  When, in
 addition to the site group-ids some group-ids are defined at the
 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 site-network-access, each constraint MUST
 be expressed against a targeted set of site-network-accesses.  This
 site-network-access MUST never be taken into account in the targeted
 set -- for example, "My site-network-access S must not be connected
 on the same POP as the site-network-accesses that are part of Group
 10."  The set of site-network-accesses against which the constraint
 is evaluated can be expressed as a list of groups, "all-other-
 accesses", or "all-other-groups".  The 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 option means that the
 constraint MUST be evaluated against all groups that the current
 site-network-access does not belong to.
 The current model defines multiple constraint-types:
 o  pe-diverse: The current site-network-access MUST NOT be connected
    to the same PE as the targeted site-network-accesses.
 o  pop-diverse: The current site-network-access MUST NOT be connected
    to the same POP as the targeted site-network-accesses.
 o  linecard-diverse: The current site-network-access MUST NOT be
    connected to the same linecard as the targeted site-network-
    accesses.
 o  bearer-diverse: 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
    site-network-accesses must not use the same DSLAM, BAS, or Layer 2
    switch.
 o  same-pe: The current site-network-access MUST be connected to the
    same PE as the targeted site-network-accesses.
 o  same-bearer: 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.

Wu, et al. Standards Track [Page 51] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 Each constraint is expressed as "The site-network-access S must be
 <constraint-type> (e.g., pe-diverse, pop-diverse) from these <target>
 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 the access points in the group.  As
 an example, if we want a set of sites (Site#1 to 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 with the
 following XML snippet:

<?xml version="1.0"?> <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">

<vpn-services>
 <vpn-service>
  <vpn-id>VPNA</vpn-id>
 </vpn-service>
</vpn-services>
<sites>
 <site>
  <site-id>SITE1</site-id>
  <locations>
   <location>
    <location-id>L1</location-id>
   </location>
  </locations>
  <management>
   <type>customer-managed</type>
  </management>
  <site-network-accesses>
   <site-network-access>
    <site-network-access-id>1</site-network-access-id>
    <ip-connection>
     <ipv4>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv4>
     <ipv6>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv6>
    </ip-connection>
    <service>
     <svc-mtu>1514</svc-mtu>
     <svc-input-bandwidth>10000000</svc-input-bandwidth>
     <svc-output-bandwidth>10000000</svc-output-bandwidth>
    </service>
    <security>

Wu, et al. Standards Track [Page 52] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

     <encryption>
      <layer>layer3</layer>
     </encryption>
    </security>
    <location-reference>L1</location-reference>
    <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>
  <locations>
   <location>
    <location-id>L1</location-id>
   </location>
  </locations>
  <management>
   <type>customer-managed</type>
  </management>
  <security>
   <encryption>
    <layer>layer3</layer>
   </encryption>
  </security>
  <site-network-accesses>
   <site-network-access>
    <site-network-access-id>1</site-network-access-id>
    <ip-connection>

Wu, et al. Standards Track [Page 53] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

     <ipv4>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv4>
     <ipv6>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv6>
    </ip-connection>
    <service>
     <svc-mtu>1514</svc-mtu>
     <svc-input-bandwidth>10000000</svc-input-bandwidth>
     <svc-output-bandwidth>10000000</svc-output-bandwidth>
    </service>
    <security>
     <encryption>
      <layer>layer3</layer>
     </encryption>
    </security>
    <location-reference>L1</location-reference>
    <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>
  <locations>
   <location>
    <location-id>L1</location-id>

Wu, et al. Standards Track [Page 54] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

   </location>
  </locations>
  <management>
   <type>customer-managed</type>
  </management>
  <security>
   <encryption>
    <layer>layer3</layer>
   </encryption>
  </security>
  <site-network-accesses>
   <site-network-access>
    <site-network-access-id>1</site-network-access-id>
    <ip-connection>
     <ipv4>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv4>
     <ipv6>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv6>
    </ip-connection>
    <service>
     <svc-mtu>1514</svc-mtu>
     <svc-input-bandwidth>10000000</svc-input-bandwidth>
     <svc-output-bandwidth>10000000</svc-output-bandwidth>
    </service>
    <security>
     <encryption>
      <layer>layer3</layer>
     </encryption>
    </security>
    <location-reference>L1</location-reference>
    <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>

Wu, et al. Standards Track [Page 55] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

    </access-diversity>
    <vpn-attachment>
     <vpn-id>VPNA</vpn-id>
     <site-role>spoke-role</site-role>
    </vpn-attachment>
   </site-network-access>
  </site-network-accesses>
 </site>
</sites>

</l3vpn-svc>

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

<?xml version="1.0"?> <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">

<vpn-services>
 <vpn-service>
  <vpn-id>VPNA</vpn-id>
 </vpn-service>
</vpn-services>
<sites>
 <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>

Wu, et al. Standards Track [Page 56] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

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

Wu, et al. Standards Track [Page 57] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

      </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>
  <locations>
   <location>
    <location-id>L1</location-id>
   </location>
  </locations>
  <management>
   <type>customer-managed</type>
  </management>
  <security>
   <encryption>
    <layer>layer3</layer>
   </encryption>
  </security>
  <site-network-accesses>
   <site-network-access>
    <site-network-access-id>1</site-network-access-id>
    <ip-connection>
     <ipv4>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv4>
     <ipv6>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv6>
    </ip-connection>
    <service>
     <svc-mtu>1514</svc-mtu>

Wu, et al. Standards Track [Page 58] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

     <svc-input-bandwidth>10000000</svc-input-bandwidth>
     <svc-output-bandwidth>10000000</svc-output-bandwidth>
    </service>
    <security>
     <encryption>
      <layer>layer3</layer>
     </encryption>
    </security>
    <location-reference>L1</location-reference>
    <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>
</sites>

</l3vpn-svc>

6.6.5. Infeasible Access Placement

 Some infeasible access placement scenarios could be created via the
 proposed configuration framework.  Such infeasible access placement
 scenarios could result from constraints that are too restrictive,
 leading to infeasible access placement in the network or conflicting
 constraints that would also lead to infeasible access placement.  An
 example of conflicting rules would be to request that site-network-
 access#1 be pe-diverse from site-network-access#2 and to request at
 the same time that site-network-access#2 be on the same PE as site-

Wu, et al. Standards Track [Page 59] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 network-access#1.  When the management system cannot determine the
 placement of a site-network-access, it MUST return an error message
 indicating that placement was not possible.

6.6.6. Examples of 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; for resiliency purposes, the
 customer wants the two site-network-accesses to be meshed on
 different POPs.
                                                   POP#1
           +-------+                            +---------+
           |       |                            |   PE1   |
           |       |---site-network-access#1----|   PE2   |
           |       |                            |   PE3   |
           |       |                            +---------+
           | Site#1|
           |       |                               POP#2
           |       |                            +---------+
           |       |                            |   PE4   |
           |       |---site-network-access#2----|   PE5   |
           |       |                            |   PE6   |
           |       |                            +---------+
           +-------+
 This scenario can be expressed with the following XML snippet:

<?xml version="1.0"?> <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">

<vpn-services>
 <vpn-service>
  <vpn-id>VPNA</vpn-id>
 </vpn-service>
</vpn-services>
<sites>
 <site>
  <site-id>SITE1</site-id>
  <locations>
   <location>
    <location-id>L1</location-id>
   </location>
  </locations>
  <management>
   <type>customer-managed</type>
  </management>

Wu, et al. Standards Track [Page 60] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

  <security>
   <encryption>
    <layer>layer3</layer>
   </encryption>
  </security>
  <site-network-accesses>
   <site-network-access>
    <site-network-access-id>1</site-network-access-id>
    <ip-connection>
     <ipv4>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv4>
     <ipv6>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv6>
    </ip-connection>
    <service>
     <svc-mtu>1514</svc-mtu>
     <svc-input-bandwidth>10000000</svc-input-bandwidth>
     <svc-output-bandwidth>10000000</svc-output-bandwidth>
    </service>
    <security>
     <encryption>
      <layer>layer3</layer>
     </encryption>
    </security>
    <location-reference>L1</location-reference>
    <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>

Wu, et al. Standards Track [Page 61] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

   </site-network-access>
   <site-network-access>
    <site-network-access-id>2</site-network-access-id>
    <ip-connection>
     <ipv4>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv4>
     <ipv6>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv6>
    </ip-connection>
    <service>
     <svc-mtu>1514</svc-mtu>
     <svc-input-bandwidth>10000000</svc-input-bandwidth>
     <svc-output-bandwidth>10000000</svc-output-bandwidth>
    </service>
    <security>
     <encryption>
      <layer>layer3</layer>
     </encryption>
    </security>
    <location-reference>L1</location-reference>
    <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>
</sites>

</l3vpn-svc>

Wu, et al. Standards Track [Page 62] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 But it can also be expressed with the following XML snippet:
    <?xml version="1.0"?>
    <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
      <vpn-services>
        <vpn-service>
          <vpn-id>VPNA</vpn-id>
        </vpn-service>
      </vpn-services>
      <sites>
        <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>

Wu, et al. Standards Track [Page 63] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

        </site>
      </sites>
    </l3vpn-svc>

6.6.6.2. Site Offload

 The customer has six branch offices in a particular region, and he
 wants to prevent having all branch offices connected on the same PE.
 He wants to express that three branch offices cannot be connected on
 the same linecard.  Also, the other branch offices must be connected
 on a different POP.  Those other branch offices cannot also be
 connected on the same linecard.
                                            POP#1
                                         +---------+
                                         |   PE1   |
                   Office#1 ---...       |   PE2   |
                   Office#2 ---...       |   PE3   |
                   Office#3 ---...       |   PE4   |
                                         +---------+
                                            POP#2
                                         +---------+
                   Office#4 ---...       |   PE5   |
                   Office#5 ---...       |   PE6   |
                   Office#6 ---...       |   PE7   |
                                         +---------+
 This scenario can be expressed as follows:
 o  We need to create two groups of sites: Group#10, which is composed
    of Office#1, Office#2, and Office#3; and Group#20, which is
    composed of Office#4, Office#5, and Office#6.
 o  Sites within Group#10 must be pop-diverse from sites within
    Group#20, and vice versa.
 o  Sites within Group#10 must be linecard-diverse from other sites in
    Group#10 (same for Group#20).

<?xml version="1.0"?> <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">

<vpn-services>
 <vpn-service>
  <vpn-id>VPNA</vpn-id>
 </vpn-service>
</vpn-services>

Wu, et al. Standards Track [Page 64] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

<sites>
 <site>
  <site-id>Office1</site-id>
  <locations>
   <location>
    <location-id>L1</location-id>
   </location>
  </locations>
  <management>
   <type>customer-managed</type>
  </management>
  <security>
   <encryption>
    <layer>layer3</layer>
   </encryption>
  </security>
  <site-network-accesses>
   <site-network-access>
    <site-network-access-id>1</site-network-access-id>
    <ip-connection>
     <ipv4>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv4>
     <ipv6>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv6>
    </ip-connection>
    <service>
     <svc-mtu>1514</svc-mtu>
     <svc-input-bandwidth>10000000</svc-input-bandwidth>
     <svc-output-bandwidth>10000000</svc-output-bandwidth>
    </service>
    <security>
     <encryption>
      <layer>layer3</layer>
     </encryption>
    </security>
    <location-reference>L1</location-reference>
    <access-diversity>
     <groups>
      <group>
       <group-id>10</group-id>
      </group>
     </groups>
     <constraints>
      <constraint>
       <constraint-type>pop-diverse</constraint-type>
       <target>

Wu, et al. Standards Track [Page 65] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

        <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>Office2</site-id>
  <locations>
   <location>
    <location-id>L1</location-id>
   </location>
  </locations>
  <management>
   <type>customer-managed</type>
  </management>
  <security>
   <encryption>
    <layer>layer3</layer>
   </encryption>
  </security>
  <site-network-accesses>
   <site-network-access>
    <site-network-access-id>1</site-network-access-id>
    <ip-connection>
     <ipv4>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv4>
     <ipv6>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv6>
    </ip-connection>

Wu, et al. Standards Track [Page 66] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

    <service>
     <svc-mtu>1514</svc-mtu>
     <svc-input-bandwidth>10000000</svc-input-bandwidth>
     <svc-output-bandwidth>10000000</svc-output-bandwidth>
    </service>
    <security>
     <encryption>
      <layer>layer3</layer>
     </encryption>
    </security>
    <location-reference>L1</location-reference>
    <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>Office3</site-id>
  <locations>
   <location>
    <location-id>L1</location-id>

Wu, et al. Standards Track [Page 67] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

   </location>
  </locations>
  <management>
   <type>customer-managed</type>
  </management>
  <security>
   <encryption>
    <layer>layer3</layer>
   </encryption>
  </security>
  <site-network-accesses>
   <site-network-access>
    <site-network-access-id>1</site-network-access-id>
    <ip-connection>
     <ipv4>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv4>
     <ipv6>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv6>
    </ip-connection>
    <service>
     <svc-mtu>1514</svc-mtu>
     <svc-input-bandwidth>10000000</svc-input-bandwidth>
     <svc-output-bandwidth>10000000</svc-output-bandwidth>
    </service>
    <security>
     <encryption>
      <layer>layer3</layer>
     </encryption>
    </security>
    <location-reference>L1</location-reference>
    <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>

Wu, et al. Standards Track [Page 68] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

       <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>Office4</site-id>
  <locations>
   <location>
    <location-id>L1</location-id>
   </location>
  </locations>
  <management>
   <type>customer-managed</type>
  </management>
  <security>
   <encryption>
    <layer>layer3</layer>
   </encryption>
  </security>
  <site-network-accesses>
   <site-network-access>
    <site-network-access-id>1</site-network-access-id>
    <ip-connection>
     <ipv4>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv4>
     <ipv6>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv6>
    </ip-connection>
    <service>
     <svc-mtu>1514</svc-mtu>
     <svc-input-bandwidth>10000000</svc-input-bandwidth>
     <svc-output-bandwidth>10000000</svc-output-bandwidth>
    </service>
    <security>

Wu, et al. Standards Track [Page 69] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

     <encryption>
      <layer>layer3</layer>
     </encryption>
    </security>
    <location-reference>L1</location-reference>
    <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>Office5</site-id>
  <locations>
   <location>
    <location-id>L1</location-id>
   </location>
  </locations>
  <management>
   <type>customer-managed</type>
  </management>
  <security>

Wu, et al. Standards Track [Page 70] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

   <encryption>
    <layer>layer3</layer>
   </encryption>
  </security>
  <site-network-accesses>
   <site-network-access>
    <site-network-access-id>1</site-network-access-id>
    <ip-connection>
     <ipv4>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv4>
     <ipv6>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv6>
    </ip-connection>
    <service>
     <svc-mtu>1514</svc-mtu>
     <svc-input-bandwidth>10000000</svc-input-bandwidth>
     <svc-output-bandwidth>10000000</svc-output-bandwidth>
    </service>
    <security>
     <encryption>
      <layer>layer3</layer>
     </encryption>
    </security>
    <location-reference>L1</location-reference>
    <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>

Wu, et al. Standards Track [Page 71] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

      </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>Office6</site-id>
  <locations>
   <location>
    <location-id>L1</location-id>
   </location>
  </locations>
  <management>
   <type>customer-managed</type>
  </management>
  <security>
   <encryption>
    <layer>layer3</layer>
   </encryption>
  </security>
  <site-network-accesses>
   <site-network-access>
    <site-network-access-id>1</site-network-access-id>
    <ip-connection>
     <ipv4>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv4>
     <ipv6>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv6>
    </ip-connection>
    <service>
     <svc-mtu>1514</svc-mtu>
     <svc-input-bandwidth>10000000</svc-input-bandwidth>
     <svc-output-bandwidth>10000000</svc-output-bandwidth>
    </service>
    <security>
     <encryption>
      <layer>layer3</layer>
     </encryption>
    </security>
    <location-reference>L1</location-reference>
    <access-diversity>

Wu, et al. Standards Track [Page 72] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

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

</l3vpn-svc>

6.6.6.3. Parallel Links

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

Site 1 *site-network-access#2 PE1

Wu, et al. Standards Track [Page 73] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 This scenario can be expressed with the following XML snippet:
    <?xml version="1.0"?>
    <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
      <vpn-services>
        <vpn-service>
          <vpn-id>VPNB</vpn-id>
        </vpn-service>
      </vpn-services>
      <sites>
        <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>

Wu, et al. Standards Track [Page 74] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

                    <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>
      </sites>
    </l3vpn-svc>

6.6.6.4. SubVPN with Multihoming

 A customer has a site that is dual-homed.  The dual-homing must be
 done on two different PEs.  The customer also wants to implement two
 subVPNs on those multihomed accesses.
 +-----------------+         Site                     +------+
 |                 |---------------------------------/       +-----+
 |                 |****(site-network-access#1)*****| VPN B /       \
 | New York Office |****(site-network-access#2)************| VPN C   |
 |                 |                                  +-----\       /
 |                 |                                         +-----+
 |                 |
 |                 |                                  +------+
 |                 |                                 /       +-----+
 |                 |****(site-network-access#3)*****| VPN B /       \
 |                 |****(site-network-access#4)************| VPN C   |
 |                 |                                  +-----\       /
 |                 |-----------------------------------      +-----+
 +-----------------+
 This scenario can be expressed as follows:
 o  The site will have four site network accesses (two subVPNs coupled
    via dual-homing).
 o  Site-network-access#1 and site-network-access#3 will correspond to
    the multihoming of subVPN B.  A PE-diverse constraint is required
    between them.

Wu, et al. Standards Track [Page 75] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 o  Site-network-access#2 and site-network-access#4 will correspond to
    the multihoming of 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 and site-network-access#2 must share the same
    bearer as site-network-access#3 and site-network-access#4.

<?xml version="1.0"?> <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">

<vpn-services>
 <vpn-service>
  <vpn-id>VPNB</vpn-id>
 </vpn-service>
 <vpn-service>
  <vpn-id>VPNC</vpn-id>
 </vpn-service>
</vpn-services>
<sites>
 <site>
  <site-id>SITE1</site-id>
  <locations>
   <location>
    <location-id>L1</location-id>
   </location>
  </locations>
  <management>
   <type>customer-managed</type>
  </management>
  <security>
   <encryption>
    <layer>layer3</layer>
   </encryption>
  </security>
  <site-network-accesses>
   <site-network-access>
    <site-network-access-id>1</site-network-access-id>
    <ip-connection>
     <ipv4>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv4>
     <ipv6>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv6>
    </ip-connection>
    <service>
     <svc-mtu>1514</svc-mtu>
     <svc-input-bandwidth>10000000</svc-input-bandwidth>

Wu, et al. Standards Track [Page 76] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

     <svc-output-bandwidth>10000000</svc-output-bandwidth>
    </service>
    <security>
     <encryption>
      <layer>layer3</layer>
     </encryption>
    </security>
    <location-reference>L1</location-reference>
    <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>

Wu, et al. Standards Track [Page 77] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

       <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>
    <ip-connection>
     <ipv4>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv4>
     <ipv6>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv6>
    </ip-connection>
    <service>
     <svc-mtu>1514</svc-mtu>
     <svc-input-bandwidth>10000000</svc-input-bandwidth>
     <svc-output-bandwidth>10000000</svc-output-bandwidth>
    </service>
    <security>
     <encryption>
      <layer>layer3</layer>
     </encryption>
    </security>
    <location-reference>L1</location-reference>
    <access-diversity>
     <groups>
      <group>
       <group-id>dualhomed-2</group-id>
      </group>

Wu, et al. Standards Track [Page 78] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

     </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>
    <ip-connection>
     <ipv4>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv4>
     <ipv6>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv6>
    </ip-connection>
    <service>
     <svc-mtu>1514</svc-mtu>
     <svc-input-bandwidth>10000000</svc-input-bandwidth>
     <svc-output-bandwidth>10000000</svc-output-bandwidth>
    </service>
    <security>
     <encryption>
      <layer>layer3</layer>
     </encryption>
    </security>
    <location-reference>L1</location-reference>
    <access-diversity>
     <groups>

Wu, et al. Standards Track [Page 79] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

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

</l3vpn-svc>

6.6.7. Route Distinguisher and VRF Allocation

 The route distinguisher (RD) is a critical parameter of PE-based
 L3VPNs as described in [RFC4364] that provides the ability to
 distinguish common addressing plans in different VPNs.  As for route
 targets (RTs), a management system is expected to allocate a VRF on
 the target PE and an RD for this VRF.
 If a VRF already exists on the target PE and the VRF fulfills the
 connectivity constraints for the site, there is no need to recreate
 another VRF, and the site MAY be meshed within this existing VRF.
 How the management system checks that an existing VRF fulfills the
 connectivity constraints for a site is out of scope for this
 document.

Wu, et al. Standards Track [Page 80] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 If no such VRF exists on the target PE, the management system has to
 initiate the creation of a new VRF on the target PE and has to
 allocate a new RD for this new VRF.
 The management system MAY apply a per-VPN or per-VRF allocation
 policy for the RD, depending on the SP's policy.  In a per-VPN
 allocation policy, all VRFs (dispatched on multiple PEs) within a VPN
 will share the same RD value.  In a per-VRF model, all VRFs should
 always have a unique RD value.  Some other allocation policies are
 also possible, and this document does not restrict the allocation
 policies to be used.
 The allocation of RDs MAY be done in the same way as RTs.  The
 examples provided in Section 6.2.1.1 could be reused in this
 scenario.
 Note that an SP MAY configure a target PE for an automated allocation
 of RDs.  In this case, there will be no need for any backend system
 to allocate an RD value.

6.7. Site 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 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 site redundancy.  The "access-priority" leaf defines a preference
 for a particular access.  This preference is used to model load-
 balancing or primary/backup scenarios.  The higher the access-
 priority value, the higher the preference will be.

Wu, et al. Standards Track [Page 81] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 The figure below describes how the access-priority attribute can be
 used.
     Hub#1 LAN (Primary/backup)          Hub#2 LAN (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 load-sharing, so all the site-
 network-accesses must use the same access-priority value.  On the
 other hand, as Hub#1 requires a primary site-network-access and a
 backup site-network-access, a higher access-priority setting will be
 configured on the primary site-network-access.
 Scenarios that are more complex can be modeled.  Let's consider a Hub
 site with five accesses to the network (A1,A2,A3,A4,A5).  The
 customer wants to load-share its traffic on A1,A2 in the nominal
 situation.  If A1 and A2 fail, the customer wants to load-share its
 traffic on A3 and A4; finally, if A1 to A4 are down, he wants to use
 A5.  We can model this easily by configuring the following access-
 priority values: A1=100, A2=100, A3=50, A4=50, A5=10.
 The access-priority scenario has some limitations.  An access-
 priority scenario like the previous one with five accesses but with
 the constraint of having traffic load-shared between A3 and A4 in the
 case where A1 OR A2 is down is not achievable.  But the authors
 believe that using the access-priority attribute will cover most of
 the deployment use cases and that the model can still be extended via
 augmentation to support additional use cases.

6.8. Traffic Protection

 The service model supports the ability to protect the traffic for a
 site.  Such protection provides a better level of availability in
 multihoming scenarios by, for example, using local-repair techniques

Wu, et al. Standards Track [Page 82] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 in case of failures.  The associated level of service guarantee would
 be based on an agreement between the customer and the SP and is out
 of scope 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 IP VPN service with three sites,
 including two dual-homed sites (Site#1 and Site#2).  For dual-homed
 sites, we consider PE1-CE1 and PE3-CE3 as primary and PE2-CE2,PE4-CE4
 as backup for the example (even if protection also applies to 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.  How the
 traffic protection will be implemented is out of scope for this
 document.  However, in such a case, we could consider traffic coming
 from a remote site (Site#1 or Site#3), where the primary path 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 for this document.  When the PE3-CE3 link
 fails, traffic is still received by PE3, but PE3 automatically
 switches traffic to the backup entry; the path will 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 security
 parameters for the site.  The security options supported in the model
 are limited but may be extended 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.

Wu, et al. Standards Track [Page 83] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

6.9.2. Encryption

 Traffic encryption can be requested on the connection.  It may be
 performed at Layer 2 or Layer 3 by selecting the appropriate
 enumeration in the "layer" leaf.  For example, an SP may use IPsec
 when a customer requests Layer 3 encryption.  The encryption profile
 can be SP defined or customer specific.
 When an SP profile is used and a key (e.g., a pre-shared key) is
 allocated by the provider to be used by a customer, the 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 a pre-shared
 key for authentication of the site connection, with the pre-shared
 key provided through the NETCONF or RESTCONF request.  A secure
 channel must be used to ensure that the pre-shared key cannot be
 intercepted.
 For security reasons, it may be necessary for the customer to change
 the pre-shared key on a regular basis.  To perform a key change, the
 user can ask the SP to change the pre-shared key by submitting a new
 pre-shared key for the site configuration (as shown below with a
 corresponding XML snippet).  This mechanism might not be hitless.

Wu, et al. Standards Track [Page 84] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

    <?xml version="1.0"?>
    <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
      <vpn-services>
        <vpn-service>
          <vpn-id>VPNA</vpn-id>
        </vpn-service>
      </vpn-services>
      <sites>
        <site>
          <site-id>SITE1</site-id>
          <site-network-accesses>
            <site-network-access>
              <site-network-access-id>1</site-network-access-id>
              <security>
                <encryption>
                  <encryption-profile>
                    <preshared-key>MY_NEW_KEY</preshared-key>
                  </encryption-profile>
                </encryption>
              </security>
            </site-network-access>
          </site-network-accesses>
        </site>
      </sites>
    </l3vpn-svc>
 A hitless key change mechanism may be added through augmentation.
 Other key-management methodologies (e.g., PKI) may be added through
 augmentation.

6.10. Management

 The model defines three types of common management options:
 o  provider-managed: 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 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 CE router is primarily managed by the provider; in
    addition, the SP allows customers to access the CE for
    configuration/monitoring purposes.  In the co-managed mode, the
    responsibility boundary is the same as the responsibility boundary
    for the provider-managed model.

Wu, et al. Standards Track [Page 85] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 Based on the management model, different security options MAY be
 derived.
 In the co-managed case, the model defines options for the management
 address family (IPv4 or IPv6) and the associated management address.

6.11. Routing Protocols

 "routing-protocol" defines which routing protocol must be activated
 between the provider and the customer router.  The current model
 supports the following settings: bgp, rip, ospf, static, direct, and
 vrrp.
 The routing protocol defined applies at the provider-to-customer
 boundary.  Depending on how the management model is administered, it
 may apply to the PE-CE boundary or the CE-to-customer boundary.  In
 the case of a customer-managed site, the routing protocol defined
 will be activated between the PE and the CE router managed by the
 customer.  In the case of a provider-managed site, the 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, we
 expect the PE-CE routing to be configured based on the SP's rules, as
 both are managed by the same entity.
                                    Rtg protocol
            192.0.2.0/24 ----- CE ----------------- PE1
                         Customer-managed site
                  Rtg protocol
            Customer router ----- CE ----------------- PE1
                         Provider-managed site
 All the examples below will refer to a scenario for a customer-
 managed site.

Wu, et al. Standards Track [Page 86] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

6.11.1. Handling of Dual Stack

 All routing protocol types support dual stack by using the "address-
 family" leaf-list.
 Example of a corresponding XML snippet with dual stack using the same
 routing protocol:
    <?xml version="1.0"?>
    <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
      <vpn-services>
        <vpn-service>
          <vpn-id>VPNA</vpn-id>
        </vpn-service>
      </vpn-services>
      <sites>
        <site>
          <site-id>SITE1</site-id>
          <routing-protocols>
            <routing-protocol>
              <type>static</type>
              <static>
                <cascaded-lan-prefixes>
                  <ipv4-lan-prefixes>
                    <lan>192.0.2.0/24</lan>
                    <next-hop>203.0.113.1</next-hop>
                  </ipv4-lan-prefixes>
                  <ipv6-lan-prefixes>
                    <lan>2001:db8::1/64</lan>
                    <next-hop>2001:db8::2</next-hop>
                  </ipv6-lan-prefixes>
                </cascaded-lan-prefixes>
              </static>
            </routing-protocol>
          </routing-protocols>
        </site>
      </sites>
    </l3vpn-svc>

Wu, et al. Standards Track [Page 87] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 Example of a corresponding XML snippet with dual stack using two
 different routing protocols:
    <?xml version="1.0"?>
    <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
      <vpn-services>
        <vpn-service>
          <vpn-id>VPNA</vpn-id>
        </vpn-service>
      </vpn-services>
      <sites>
        <site>
          <site-id>SITE1</site-id>
          <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>
                <area-address>4.4.4.4</area-address>
              </ospf>
            </routing-protocol>
          </routing-protocols>
        </site>
      </sites>
    </l3vpn-svc>

6.11.2. LAN Directly Connected to SP 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 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.

Wu, et al. Standards Track [Page 88] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

6.11.3. LAN Directly Connected to SP Network with Redundancy

 The routing protocol type "vrrp" SHOULD be used and advertised in the
 IP VPN when
 o  the customer LAN is directly connected to the provider 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 SP network.

6.11.4. Static Routing

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

6.11.5. RIP Routing

 The routing 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 IP VPN.  For IPv4, the model assumes that RIP
 version 2 is used.
 In the case of dual-stack routing requested through this model, the
 management system will be responsible for configuring RIP (including
 the correct version number) and associated address families on
 network elements.
                                       RIP rtg
               192.0.2.0/24 ------ CE -------------- PE

Wu, et al. Standards Track [Page 89] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

6.11.6. OSPF Routing

 The routing 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 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 defines an option to create an OSPF sham link between
 two sites sharing the same area and having a backdoor link.  The sham
 link is created by referencing the target site sharing the same OSPF
 area.  The management system will be responsible for checking to see
 if there is already a sham link configured for this VPN and area
 between the same pair of PEs.  If there is no existing sham link, the
 management system will provision one.  This sham link MAY be reused
 by other sites.
                  +------------------------+
                  |                        |
                  |                        |
                  |  PE (--sham link--)PE  |
                  |    |                |  |
                  +----|----------------|--+
                       | OSPF area 1    | OSPF area 1
                       |                |
                       CE1             CE2
                       |                |
                 (OSPF area 1)     (OSPF area 1)
                       |                |
                       +----------------+
 Regarding 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 version 2 and OSPF
 version 3 on the PE-CE link.

Wu, et al. Standards Track [Page 90] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 Other OSPF parameters, such as timers, are typically set by the SP
 and communicated to the customer outside the scope of this model.
 Example of a corresponding XML snippet with OSPF routing parameters
 in the service model:
    <?xml version="1.0"?>
    <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
      <vpn-services>
        <vpn-service>
          <vpn-id>VPNA</vpn-id>
        </vpn-service>
      </vpn-services>
      <sites>
        <site>
          <site-id>SITE1</site-id>
          <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>
        </site>
      </sites>
    </l3vpn-svc>
 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
                         !

Wu, et al. Standards Track [Page 91] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

6.11.7. BGP Routing

 The routing 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 IP VPN.
                                         BGP rtg
               192.0.2.0/24 ------ CE -------------- PE
 The session addressing will be derived from connection parameters as
 well as the SP's knowledge of the addressing plan that is in use.
 In the case of dual-stack access, the user MAY request BGP routing
 for both IPv4 and IPv6 by specifying both address families.  It will
 be up to the SP and management system to determine how to describe
 the configuration (two BGP sessions, single, multi-session, etc.).
 This, along with other BGP parameters such as timers, is communicated
 to the customer outside the scope of this model.
 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.  If the site-network-access connection addresses are used for
 BGP peering, the "static-address" allocation type for the IP
 connection MUST be used.  Other peering mechanisms are outside the
 scope of this model.  An example of a corresponding XML snippet is
 described as follows:
    <?xml version="1.0"?>
    <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
      <vpn-services>
        <vpn-service>
          <vpn-id>VPNA</vpn-id>
        </vpn-service>
      </vpn-services>
      <sites>
        <site>
          <site-id>SITE1</site-id>
          <routing-protocols>
            <routing-protocol>
              <type>bgp</type>
              <bgp>
                <autonomous-system>65000</autonomous-system>
                <address-family>ipv4</address-family>
                <address-family>ipv6</address-family>
              </bgp>
            </routing-protocol>

Wu, et al. Standards Track [Page 92] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

          </routing-protocols>
        </site>
      </sites>
    </l3vpn-svc>
 Depending on the SP flavor, a management system can divide this
 service configuration into different flavors, as shown by the
 following examples.
 Example of PE configuration done by the management system (single
 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 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 of PE configuration done by the management system (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.

Wu, et al. Standards Track [Page 93] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

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
 second.  The input/output direction uses the customer site as a
 reference: "input bandwidth" means download bandwidth for the site,
 and "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 the SP to
 determine if the customer allows for asymmetric bandwidth access,
 such as ADSL.  It can also be used to set rate-limiting in a
 different way for uploading and downloading on a symmetric bandwidth
 access.
 The bandwidth is a service bandwidth expressed primarily as IP
 bandwidth, but if the customer enables MPLS for Carriers' Carriers
 (CsC), this becomes MPLS bandwidth.

6.12.2. MTU

 The service MTU refers to the maximum PDU size that the customer may
 use.  If the customer sends packets that are longer than the
 requested service MTU, the network may discard it (or for IPv4,
 fragment it).

6.12.3. QoS

 The model defines QoS parameters in an abstracted way:
 o  qos-classification-policy: policy that defines a set of ordered
    rules to classify customer traffic.
 o  qos-profile: QoS scheduling profile to be applied.

6.12.3.1. QoS Classification

 QoS classification rules are handled by 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 flow definition
 that is more specific (e.g., based on Layer 3 source and destination
 addresses, Layer 4 ports, and Layer 4 protocol).  When a flow
 definition is used, the user can employ a "target-sites" leaf-list to

Wu, et al. Standards Track [Page 94] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 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 for this
 document.  The association of a site to an IP VPN is done through the
 "vpn-attachment" container.  Therefore, the user can also employ
 "target-sites" leaf-list and "vpn-attachment" to identify the
 destination of a flow targeted to a specific VPN service.  A rule
 that does not have a match statement is considered a match-all rule.
 An SP may implement a default terminal classification rule if the
 customer does not provide it.  It will be up to the SP to determine
 its default target class.  The current model defines some
 applications, but new application identities may be added through
 augmentation.  The exact meaning of each application identity is up
 to the SP, so it will be necessary for the SP to advise the customer
 on the usage of application matching.
 Where the classification is done depends on the 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.
 o  in the ingress direction on the CE interface connected to the
    customer LAN, if the CE is provider-managed.
 The figure below describes a sample service description of QoS
 classification for a site:
   <?xml version="1.0"?>
   <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
     <vpn-services>
       <vpn-service>
         <vpn-id>VPNA</vpn-id>
       </vpn-service>

Wu, et al. Standards Track [Page 95] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

     </vpn-services>
     <sites>
       <site>
         <site-id>SITE1</site-id>
         <service>
           <qos>
             <qos-classification-policy>
               <rule>
                 <id>SvrA-http</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>
                   <protocol-type>tcp</protocol-type>
                 </match-flow>
                 <target-class-id>DATA2</target-class-id>
               </rule>
               <rule>
                 <id>SvrA-ftp</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>
                   <protocol-field>tcp</protocol-field>
                 </match-flow>
                 <target-class-id>DATA2</target-class-id>
               </rule>
               <rule>
                 <id>p2p</id>
                 <match-application>p2p</match-application>
                 <target-class-id>DATA3</target-class-id>
               </rule>
               <rule>
                 <id>any</id>
                 <target-class-id>DATA1</target-class-id>
               </rule>
             </qos-classification-policy>
           </qos>
         </service>
       </site>
     </sites>
   </l3vpn-svc>
 In the example above:
 o  HTTP traffic from the 192.0.2.0/24 LAN destined for 203.0.113.1/32
    will be classified in DATA2.

Wu, et al. Standards Track [Page 96] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 o  FTP traffic from the 192.0.2.0/24 LAN destined for 203.0.113.1/32
    will be classified in DATA2.
 o  Peer-to-peer traffic will be classified in DATA3.
 o  All other traffic will be classified in DATA1.
 The order of rule list entries is defined by the user.  The
 management system responsible for translating those rules in network
 element configuration MUST keep the same processing order in network
 element configuration.

6.12.3.2. QoS Profile

 The user can choose either a standard profile provided by the
 operator or a custom profile.  The "qos-profile" container defines
 the traffic-scheduling policy to be used by the SP.
                                         Provider network
                                    +-----------------------+
          192.0.2.0/24
          198.51.100.0/24 ---- CE --------- PE
                                  \       /
                                 qos-profile
 A custom QoS profile is defined as a list of classes of services and
 associated properties.  The properties are as follows:
 o  direction: used to specify the direction to which the QoS profile
    is applied.  This model supports three direction settings: "Site-
    to-WAN", "WAN-to-Site", and "both".  By default, the "both"
    direction value is used.  If the direction is "both", the provider
    should ensure scheduling according to the requested policy in both
    traffic directions (SP to customer and customer to SP).  As an
    example, a device-scheduling policy may be implemented on both the
    PE side and the CE side of the WAN link.  If the direction is
    "WAN-to-Site", the provider should ensure scheduling from the SP
    network to the customer site.  As an example, a device-scheduling
    policy may be implemented only on the PE side of the WAN link
    towards the customer.
 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 on the CE side,
    svc-output-bandwidth is taken into account as a reference.  When
    it is implemented on the PE side, svc-input-bandwidth is used.

Wu, et al. Standards Track [Page 97] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 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 SP's implementation of
    the service: a strict priority queuing may be used on the access
    and in the core network, and/or a 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 SP's implementation of
    the service: a strict priority 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" parameter uses available bandwidth as a
    reference.  When the qos-profile container is implemented on the
    CE side, svc-output-bandwidth is taken into account as a
    reference.  When it is implemented on the PE side, 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, 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.
 In addition, due to network conditions, some constraints may not be
 completely fulfilled by the SP; in this case, the SP should advise
 the customer about the limitations.  How this communication is done
 is out of scope for this document.
 Example of service configuration using a standard QoS profile with
 the following corresponding XML snippet:

<?xml version="1.0"?> <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc"> <vpn-profiles>

<valid-provider-identifiers>
 <qos-profile-identifier>
  <id>GOLD</id>
 </qos-profile-identifier>
 <qos-profile-identifier>
  <id>PLATINUM</id>

Wu, et al. Standards Track [Page 98] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 </qos-profile-identifier>
</valid-provider-identifiers>

</vpn-profiles> <vpn-services>

<vpn-service>
 <vpn-id>VPNA</vpn-id>
</vpn-service>

</vpn-services> <sites>

<site>
 <site-id>SITE1</site-id>
 <locations>
  <location>
   <location-id>L1</location-id>
  </location>
 </locations>
 <site-network-accesses>
  <site-network-access>
   <site-network-access-id>1245HRTFGJGJ154654</site-network-access-id>
   <vpn-attachment>
    <vpn-id>VPNA</vpn-id>
    <site-role>spoke-role</site-role>
   </vpn-attachment>
   <ip-connection>
    <ipv4>
     <address-allocation-type>provider-dhcp</address-allocation-type>
    </ipv4>
    <ipv6>
     <address-allocation-type>provider-dhcp</address-allocation-type>
    </ipv6>
   </ip-connection>
   <security>
    <encryption>
     <layer>layer3</layer>
    </encryption>
   </security>
   <location-reference>L1</location-reference>
   <service>
    <svc-input-bandwidth>100000000</svc-input-bandwidth>
    <svc-output-bandwidth>100000000</svc-output-bandwidth>
    <svc-mtu>1514</svc-mtu>
    <qos>
     <qos-profile>
      <profile>PLATINUM</profile>
     </qos-profile>
    </qos>
   </service>
  </site-network-access>

Wu, et al. Standards Track [Page 99] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

  <site-network-access>
   <site-network-access-id>555555AAAA2344</site-network-access-id>
   <vpn-attachment>
    <vpn-id>VPNA</vpn-id>
    <site-role>spoke-role</site-role>
   </vpn-attachment>
   <ip-connection>
    <ipv4>
     <address-allocation-type>provider-dhcp</address-allocation-type>
    </ipv4>
    <ipv6>
     <address-allocation-type>provider-dhcp</address-allocation-type>
    </ipv6>
   </ip-connection>
   <security>
    <encryption>
     <layer>layer3</layer>
    </encryption>
   </security>
   <location-reference>L1</location-reference>
   <service>
    <svc-input-bandwidth>2000000</svc-input-bandwidth>
    <svc-output-bandwidth>2000000</svc-output-bandwidth>
    <svc-mtu>1514</svc-mtu>
    <qos>
     <qos-profile>
      <profile>GOLD</profile>
     </qos-profile>
    </qos>
   </service>
  </site-network-access>
 </site-network-accesses>
</site>

</sites> </l3vpn-svc>

 Example of service configuration using a custom QoS profile with the
 following corresponding XML snippet:

<?xml version="1.0"?> <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">

<vpn-profiles>
 <valid-provider-identifiers>
  <qos-profile-identifier>
   <id>GOLD</id>
  </qos-profile-identifier>
  <qos-profile-identifier>
   <id>PLATINUM</id>

Wu, et al. Standards Track [Page 100] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

  </qos-profile-identifier>
 </valid-provider-identifiers>
</vpn-profiles>
<vpn-services>
 <vpn-service>
  <vpn-id>VPNA</vpn-id>
 </vpn-service>
</vpn-services>
<sites>
 <site>
  <site-id>SITE1</site-id>
  <locations>
   <location>
    <location-id>L1</location-id>
   </location>
  </locations>
  <site-network-accesses>
   <site-network-access>
    <site-network-access-id>Site1</site-network-access-id>
    <location-reference>L1</location-reference>
    <ip-connection>
     <ipv4>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv4>
     <ipv6>
      <address-allocation-type>provider-dhcp</address-allocation-type>
     </ipv6>
    </ip-connection>
    <service>
     <svc-mtu>1514</svc-mtu>
     <svc-input-bandwidth>10000000</svc-input-bandwidth>
     <svc-output-bandwidth>10000000</svc-output-bandwidth>
    </service>
    <security>
     <encryption>
      <layer>layer3</layer>
     </encryption>
    </security>
    <location-reference>L1</location-reference>
    <vpn-attachment>
     <vpn-id>VPNA</vpn-id>
     <site-role>spoke-role</site-role>
    </vpn-attachment>
    <service>
     <svc-input-bandwidth>100000000</svc-input-bandwidth>
     <svc-output-bandwidth>100000000</svc-output-bandwidth>
     <qos>
      <qos-profile>

Wu, et al. Standards Track [Page 101] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

       <classes>
        <class>
         <class-id>REAL_TIME</class-id>
         <direction>both</direction>
         <rate-limit>10</rate-limit>
         <latency>
          <use-lowest-latency/>
         </latency>
         <bandwidth>
          <guaranteed-bw-percent>80</guaranteed-bw-percent>
         </bandwidth>
        </class>
        <class>
         <class-id>DATA1</class-id>
         <latency>
          <latency-boundary>70</latency-boundary>
         </latency>
         <bandwidth>
          <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>
          <end-to-end/>
         </bandwidth>
        </class>
       </classes>
      </qos-profile>
     </qos>
    </service>
   </site-network-access>
  </site-network-accesses>
 </site>
</sites>

</l3vpn-svc>

 The custom QoS profile for Site1 defines a REAL_TIME class with a
 latency constraint expressed as the lowest possible latency.  It also
 defines two data classes -- DATA1 and DATA2.  The two classes express
 a latency boundary constraint as well as a bandwidth reservation, as
 the REAL_TIME class is rate-limited to 10% of the service bandwidth
 (10% of 100 Mbps = 10 Mbps).  In cases where congestion occurs, the
 REAL_TIME traffic can go up to 10 Mbps (let's assume that only 5 Mbps

Wu, et al. Standards Track [Page 102] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 are consumed).  DATA1 and DATA2 will share the remaining bandwidth
 (95 Mbps) according to their percentage.  So, the DATA1 class will be
 served with at least 76 Mbps of bandwidth, while the DATA2 class will
 be served with at least 4.75 Mbps.  The latency boundary information
 of the data class may help the 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 SP.

6.12.4. Multicast

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

Wu, et al. Standards Track [Page 103] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

6.13. Enhanced VPN Features

6.13.1. Carriers' Carriers

 In the case of CsC [RFC4364], a customer may want to build an MPLS
 service using an IP VPN to carry its traffic.
                LAN customer1
                    |
                    |
                   CE1
                    |
                    | -------------
                 (vrf_cust1)
                  CE1_ISP1
                    |                 ISP1 POP
                    | MPLS link
                    | -------------
                    |
                 (vrf ISP1)
                   PE1
                  (...)               Provider backbone
                   PE2
                  (vrf ISP1)
                    |
                    | ------------
                    |
                    | MPLS link
                    |                 ISP1 POP
                   CE2_ISP1
                   (vrf_cust1)
                    | ------------
                    |
                   CE2
                    |
                 LAN customer1
 In the figure above, ISP1 resells an IP VPN service but has no core
 network infrastructure between its POPs.  ISP1 uses an IP VPN as the
 core network infrastructure (belonging to another provider) between
 its POPs.

Wu, et al. Standards Track [Page 104] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 In order to support CsC, the VPN service must indicate MPLS support
 by setting the "carrierscarrier" leaf to true in 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 the routing protocol.
 If CsC is enabled, the requested "svc-mtu" leaf will refer to the
 MPLS MTU and not to the IP MTU.

6.14. External ID 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 (CSP), the model uses an identifier to refer
 to the targeted CSP.  If a customer is directly using this service
 model as an API (through REST or NETCONF, for example) to order a
 particular service, the SP should provide a list of authorized
 identifiers.  In the case of cloud-access, the SP will provide the
 associated identifiers for each available CSP.  The same applies to
 other identifiers, such as std-qos-profile, OAM profile-name, and
 provider-profile for encryption.
 How an SP provides the meanings of those identifiers to the customer
 is out of scope 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 different ASes in different geographic areas or span
 different SPs.  The connection between ASes is established by the SPs
 and is seamless to the customer.  Examples include
 o  a partnership between SPs (e.g., carrier, cloud) to extend their
    VPN service seamlessly.
 o  an internal administrative boundary within a single SP (e.g.,
    backhaul versus core versus data center).
 NNIs (network-to-network interfaces) have to be defined to extend the
 VPNs across multiple ASes.

Wu, et al. Standards Track [Page 105] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 [RFC4364] defines multiple flavors of VPN NNI implementations.  Each
 implementation has pros and cons; this topic is outside the scope of
 this document.  For example, in an Inter-AS option A, autonomous
 system border router (ASBR) peers are connected by multiple
 interfaces with at least one of those interfaces spanning the two
 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.  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 (SLAs).
  1. ——- ————– ———–

/ \ / \ / \

 | Cloud    |             |                |          |             |
 | Provider |-----NNI-----|                |----NNI---| Data Center |
 |  #1      |             |                |          |             |
  \        /              |                |           \           /
   --------               |                |            -----------
                          |                |
   --------               |   My network   |           -----------
  /        \              |                |          /           \
 | Cloud    |             |                |         |             |
 | Provider |-----NNI-----|                |---NNI---|  L3VPN      |
 |  #2      |             |                |         |  Partner    |
  \        /              |                |         |             |
   --------               |                |         |             |
                           \              /          |             |
                            --------------            \           /
                                  |                    -----------
                                  |
                                 NNI
                                  |
                                  |
                          -------------------
                         /                   \
                        |                     |
                        |                     |
                        |                     |
                        |     L3VPN Partner   |
                        |                     |
                         \                   /
                          -------------------

Wu, et al. Standards Track [Page 106] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 The figure above describes an SP network called "My network" that has
 several NNIs.  This network uses NNIs to:
 o  increase its footprint by relying on L3VPN partners.
 o  connect its own data center services to the customer IP VPN.
 o  enable the customer to access its private resources located in a
    private cloud owned by some CSPs.

6.15.1. Defining an NNI with the Option A Flavor

           AS A                                          AS B
    -------------------                         -------------------
   /                   \                       /                   \
  |                     |                     |                     |
  |                 ++++++++ Inter-AS link ++++++++                 |
  |                 +      +_______________+      +                 |
  |                 +  (VRF1)---(VPN1)----(VRF1)  +                 |
  |                 + ASBR +               + ASBR +                 |
  |                 +  (VRF2)---(VPN2)----(VRF2)  +                 |
  |                 +      +_______________+      +                 |
  |                 ++++++++               ++++++++                 |
  |                     |                     |                     |
  |                     |                     |                     |
  |                     |                     |                     |
  |                 ++++++++ Inter-AS link ++++++++                 |
  |                 +      +_______________+      +                 |
  |                 +  (VRF1)---(VPN1)----(VRF1)  +                 |
  |                 + ASBR +               + ASBR +                 |
  |                 +  (VRF2)---(VPN2)----(VRF2)  +                 |
  |                 +      +_______________+      +                 |
  |                 ++++++++               ++++++++                 |
  |                     |                     |                     |
  |                     |                     |                     |
   \                   /                       \                   /
    -------------------                         -------------------
 In option A, the two ASes are connected to each other with physical
 links on ASBRs.  For resiliency purposes, there may be multiple
 physical connections between the ASes.  A VPN connection -- physical
 or logical (on top of physical) -- is created for each VPN that needs
 to cross the AS boundary, thus providing a back-to-back VRF model.
 From a service model's perspective, this VPN connection can be seen
 as a site.  Let's say that AS B wants to extend some VPN connections
 for VPN C on AS A.  The administrator of AS B can use this service
 model to order a site on AS A.  All connection scenarios could be

Wu, et al. Standards Track [Page 107] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 realized using the features of the current model.  As an example, the
 figure above shows two physical connections that have logical
 connections per VPN overlaid on them.  This could be seen as a dual-
 homed subVPN scenario.  Also, the administrator of AS B will be able
 to choose the appropriate routing protocol (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 its CSP A to attach its virtual network N
 to an existing IP VPN (VPN1) that he has from L3VPN SP B.
         CSP A                              L3VPN SP B
  1. —————- ——————-

/ \ / \

 |       |           |                |                     |
 |  VM --|       ++++++++  NNI    ++++++++                  |--- VPN1
 |       |       +      +_________+      +                  |   Site#1
 |       |--------(VRF1)---(VPN1)--(VRF1)+                  |
 |       |       + ASBR +         + ASBR +                  |
 |       |       +      +_________+      +                  |
 |       |       ++++++++         ++++++++                  |
 |  VM --|           |                |                     |--- VPN1
 |       |Virtual    |                |                     |   Site#2
 |       |Network    |                |                     |
 |  VM --|           |                |                     |--- VPN1
 |       |           |                |                     |   Site#3
  \                 /                  \                   /
   -----------------                    -------------------
                                                |
                                                |
                                              VPN1
                                             Site#4
 To create the VPN connectivity, the CSP or the customer may use the
 L3VPN service model that SP B 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 with a single site-network-access (single-
 homing is used in the 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 snippet below
 illustrates a possible configuration request to SP B:

Wu, et al. Standards Track [Page 108] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

<?xml version="1.0"?> <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc"> <vpn-profiles>

<valid-provider-identifiers>
 <qos-profile-identifier>
  <id>GOLD</id>
 </qos-profile-identifier>
 <qos-profile-identifier>
  <id>PLATINUM</id>
 </qos-profile-identifier>
</valid-provider-identifiers>

</vpn-profiles> <vpn-services>

<vpn-service>
 <vpn-id>VPN1</vpn-id>
</vpn-service>

</vpn-services> <sites>

<site>
 <site-id>CSP_A_attachment</site-id>
 <security>
  <encryption>
   <layer>layer3</layer>
  </encryption>
 </security>
 <locations>
  <location>
   <location-id>L1</location-id>
  </location>
 </locations>
 <locations>
  <location>
   <location-id>1</location-id>
   <city>NY</city>
   <country-code>US</country-code>
  </location>
 </locations>
 <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>

Wu, et al. Standards Track [Page 109] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

  <site-network-access>
   <site-network-access-id>CSP_A_VN1</site-network-access-id>
   <location-reference>L1</location-reference>
   <ip-connection>
    <ipv4>
     <address-allocation-type>provider-dhcp</address-allocation-type>
    </ipv4>
    <ipv6>
     <address-allocation-type>provider-dhcp</address-allocation-type>
    </ipv6>
   </ip-connection>
   <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>
      <prefix-length>30</prefix-length>
     </addresses>
    </ipv4>
   </ip-connection>
   <service>
    <svc-input-bandwidth>450000000</svc-input-bandwidth>
    <svc-output-bandwidth>450000000</svc-output-bandwidth>
    <svc-mtu>1514</svc-mtu>
   </service>
   <security>
    <encryption>
     <layer>layer3</layer>
    </encryption>
   </security>
   <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>

</sites> </l3vpn-svc>

 The case described above is different from a scenario using the
 cloud-accesses container, as the cloud-access provides a public cloud
 access while this example enables access to private resources located
 in a CSP network.

Wu, et al. Standards Track [Page 110] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

6.15.2. Defining an NNI with the Option B Flavor

          AS A                                          AS B
    -------------------                         -------------------
   /                   \                       /                   \
  |                     |                     |                     |
  |                 ++++++++ Inter-AS link ++++++++                 |
  |                 +      +_______________+      +                 |
  |                 +      +               +      +                 |
  |                 + ASBR +<---MP-BGP---->+ ASBR +                 |
  |                 +      +               +      +                 |
  |                 +      +_______________+      +                 |
  |                 ++++++++               ++++++++                 |
  |                     |                     |                     |
  |                     |                     |                     |
  |                     |                     |                     |
  |                 ++++++++ Inter-AS link ++++++++                 |
  |                 +      +_______________+      +                 |
  |                 +      +               +      +                 |
  |                 + ASBR +<---MP-BGP---->+ ASBR +                 |
  |                 +      +               +      +                 |
  |                 +      +_______________+      +                 |
  |                 ++++++++               ++++++++                 |
  |                     |                     |                     |
  |                     |                     |                     |
   \                   /                       \                   /
    -------------------                         -------------------
 In option B, the two ASes are connected to each other with physical
 links on ASBRs.  For resiliency purposes, there may be multiple
 physical connections between the ASes.  The VPN "connection" between
 ASes is done by exchanging VPN routes through MP-BGP [RFC4760].
 There are multiple flavors of implementations of such an NNI.  For
 example:
 1.  The NNI is internal to the provider and is situated between a
     backbone and a data center.  There is enough trust between the
     domains to not filter the VPN routes.  So, all the VPN routes are
     exchanged.  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 RTs only.  Each provider is authorized to use
     the RT values from the other provider.

Wu, et al. Standards Track [Page 111] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 3.  The NNI is used between providers that agreed to exchange VPN
     routes for specific RTs only.  Each provider has its own RT
     scheme.  So, a customer spanning the two networks will have
     different 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 that an RT-filtering policy on ASBRs be maintained.
 From a service modeling point of view, it is necessary to agree on
 the list of RTs to authorize.
 In Case 3, both ASes need to agree on the VPN RT to exchange, as well
 as how to map a VPN RT from AS A to the corresponding RT in AS B (and
 vice versa).
 Those modelings are currently out of scope for this document.
        CSP A                               L3VPN SP B
  1. —————- ——————

/ \ / \

 |       |           |                |                    |
 |  VM --|       ++++++++   NNI    ++++++++                |--- VPN1
 |       |       +      +__________+      +                |   Site#1
 |       |-------+      +          +      +                |
 |       |       + ASBR +<-MP-BGP->+ ASBR +                |
 |       |       +      +__________+      +                |
 |       |       ++++++++          ++++++++                |
 |  VM --|           |                |                    |--- VPN1
 |       |Virtual    |                |                    |   Site#2
 |       |Network    |                |                    |
 |  VM --|           |                |                    |--- VPN1
 |       |           |                |                    |   Site#3
  \                 /                 |                    |
   -----------------                  |                    |
                                       \                  /
                                        ------------------
                                                 |
                                                 |
                                                VPN1
                                               Site#4
 The example above describes an NNI connection between CSP A and SP
 network B.  Both SPs do not trust themselves and use a different RT
 allocation policy.  So, in terms of implementation, the customer VPN
 has a different RT in each network (RT A in CSP A and RT B in SP
 network B).  In order to connect the customer virtual network in CSP

Wu, et al. Standards Track [Page 112] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 A to the customer IP VPN (VPN1) in SP network B, CSP A should request
 that SP network B open the customer VPN on the NNI (accept the
 appropriate RT).  Who does the RT translation depends on the
 agreement between the two SPs: SP B may permit CSP A to request VPN
 (RT) translation.

6.15.3. Defining an NNI with the Option C Flavor

          AS A                                           AS B
   -------------------                          -------------------
  /                   \                        /                   \
 |                     |                      |                     |
 |                     |                      |                     |
 |                     |                      |                     |
 |                 ++++++++ Multihop E-BGP ++++++++                 |
 |                 +      +                +      +                 |
 |                 +      +                +      +                 |
 |                 + RGW  +<----MP-BGP---->+ RGW  +                 |
 |                 +      +                +      +                 |
 |                 +      +                +      +                 |
 |                 ++++++++                ++++++++                 |
 |                     |                      |                     |
 |                     |                      |                     |
 |                     |                      |                     |
 |                     |                      |                     |
 |                     |                      |                     |
 |                 ++++++++ Inter-AS link ++++++++                  |
 |                 +      +_______________+      +                  |
 |                 +      +               +      +                  |
 |                 + ASBR +               + ASBR +                  |
 |                 +      +               +      +                  |
 |                 +      +_______________+      +                  |
 |                 ++++++++               ++++++++                  |
 |                     |                      |                     |
 |                     |                      |                     |
 |                     |                      |                     |
 |                 ++++++++ Inter-AS link ++++++++                  |
 |                 +      +_______________+      +                  |
 |                 +      +               +      +                  |
 |                 + ASBR +               + ASBR +                  |
 |                 +      +               +      +                  |
 |                 +      +_______________+      +                  |
 |                 ++++++++               ++++++++                  |
 |                     |                      |                     |
 |                     |                      |                     |
  \                   /                        \                   /
   -------------------                          -------------------

Wu, et al. Standards Track [Page 113] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 From a VPN service's perspective, the option C NNI is very similar to
 option 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.
 From a VPN service's point of view, modeling options B and C will be
 identical.

7. Service 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 of how a management system can use
 this model to configure an IP VPN service on network elements.
 In this example, we want to achieve the provisioning of a VPN service
 for three sites using a Hub-and-Spoke VPN service topology.  One of
 the sites will be dual-homed, and load-sharing is expected.
    +-------------------------------------------------------------+
    |   Hub_Site  ------ PE1               PE2 ------ Spoke_Site1 |
    |      |                   +----------------------------------+
    |      |                   |
    |      |                   +----------------------------------+
    |   Hub_Site  ------ PE3               PE4 ------ Spoke_Site2 |
    +-------------------------------------------------------------+
 The following XML snippet describes the overall simplified service
 configuration of this VPN.

Wu, et al. Standards Track [Page 114] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

    <?xml version="1.0"?>
    <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
      <vpn-profiles>
        <valid-provider-identifiers>
          <qos-profile-identifier>
            <id>GOLD</id>
          </qos-profile-identifier>
          <qos-profile-identifier>
            <id>PLATINUM</id>
          </qos-profile-identifier>
        </valid-provider-identifiers>
      </vpn-profiles>
      <vpn-services>
        <vpn-service>
          <vpn-id>12456487</vpn-id>
          <vpn-service-topology>hub-spoke</vpn-service-topology>
        </vpn-service>
      </vpn-services>
    </l3vpn-svc>
 When receiving the request for provisioning the VPN service, the
 management system will internally (or through communication with
 another OSS component) allocate VPN RTs.  In this specific case, two
 RTs will be allocated (100:1 for Hub and 100:2 for Spoke).  The
 output of corresponding XML snippet below describes the configuration
 of Spoke_Site1.

<?xml version="1.0"?> <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc"> <vpn-profiles>

<valid-provider-identifiers>
 <qos-profile-identifier>
  <id>GOLD</id>
 </qos-profile-identifier>
 <qos-profile-identifier>
  <id>PLATINUM</id>
 </qos-profile-identifier>
</valid-provider-identifiers>

</vpn-profiles> <vpn-services>

<vpn-service>
 <vpn-id>12456487</vpn-id>
 <vpn-service-topology>hub-spoke</vpn-service-topology>
</vpn-service>

</vpn-services> <sites>

<site>
 <site-id>Spoke_Site1</site-id>

Wu, et al. Standards Track [Page 115] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 <devices>
  <device>
   <device-id>D1</device-id>
  </device>
 </devices>
 <locations>
  <location>
   <location-id>1</location-id>
   <city>NY</city>
   <country-code>US</country-code>
  </location>
 </locations>
 <security>
  <encryption>
   <layer>layer3</layer>
  </encryption>
 </security>
 <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>
   <device-reference>D1</device-reference>
   <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>

Wu, et al. Standards Track [Page 116] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

   <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>
      <prefix-length>24</prefix-length>
     </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>
      <prefix-length>64</prefix-length>
     </addresses>
    </ipv6>
   </ip-connection>
   <service>
    <svc-input-bandwidth>450000000</svc-input-bandwidth>
    <svc-output-bandwidth>450000000</svc-output-bandwidth>
    <svc-mtu>1514</svc-mtu>
   </service>
   <security>
    <encryption>
     <layer>layer3</layer>
    </encryption>
   </security>
   <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>

</sites> </l3vpn-svc>

 When receiving the request for provisioning Spoke_Site1, the
 management system MUST allocate network resources for this site.  It
 MUST first determine the target network elements to provision the
 access, particularly the PE router (and perhaps also an aggregation
 switch).  As described in Section 6.6, the management system SHOULD
 use the location information and MUST use the access-diversity
 constraint to find the appropriate PE.  In this case, we consider

Wu, et al. Standards Track [Page 117] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 that Spoke_Site1 requires PE diversity with the Hub and that the
 management system allocates PEs based on the least distance.  Based
 on the location information, the management system finds the
 available PEs in the area nearest the customer and picks one that
 fits the 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
 pool of available PEs.  The management system can start provisioning
 the chosen PE node via whatever means the management system prefers
 (e.g., NETCONF, CLI).  The management system will check to see if a
 VRF that fits its needs is already present.  If not, it will
 provision the VRF: the RD will be derived from the internal
 allocation policy model, and the RTs will be derived from the VPN
 policy configuration of the site (the management system allocated
 some RTs for the VPN).  As the site is a Spoke site (site-role), the
 management system knows which RTs must be imported and exported.  As
 the site is provider-managed, some management 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 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; because this model is
 provider-managed, the choices are left to the SP.  BGP was chosen for
 this example.  This choice is independent of the routing protocol
 chosen by the 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-
 managed, the CE's AS number can be automatically allocated by the
 management system.  Standard configuration templates provided by the
 SP may also be added.

Wu, et al. Standards Track [Page 118] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 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 remote-as 65000   <---- Comes from
                                                  automated allocation
   neighbor 2001:db8::0a10:2 route-map STD in  <---- Standard SP
                                                        config
   neighbor 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 before sending the CE configuration to the
 customer premises.  The CE configuration will be built in the same
 way as the PE would be configured.  Based on the CE type (vendor/
 model) allocated to the customer 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 SP OSS, as both resources are managed internally.  CE-to-
 LAN-interface parameters 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 a plug-and-play configuration for the CE to be
 created.

Wu, et al. Standards Track [Page 119] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

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

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

Wu, et al. Standards Track [Page 120] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 The management system's role will be to configure the network
 elements.  The management system may be modular, so the component
 instantiating the service model (let's call it "service component")
 and the component responsible for network element configuration
 (let's call it "configuration component") may be different.
           l3vpn-svc         |
             Model           |
                             |
                  +---------------------+
                  |  Service component  | Service datastore
                  +---------------------+
                             |
                             |
                  +---------------------+
             +----|  Config component   |------+
            /     +---------------------+       \   Network
           /            /            \           \  Configuration
          /            /              \           \ models
         /            /                \           \
 ++++++++         ++++++++           ++++++++       ++++++++
 + CE A + ------- + PE A +           + PE B + ----- + CE B + Config
 ++++++++         ++++++++           ++++++++       ++++++++ datastore
          Site A                              Site B
 In the previous sections, we provided some examples of the
 translation of service provisioning requests to router configuration
 lines.  In the NETCONF/YANG ecosystem, we expect NETCONF/YANG to be
 used between the configuration component and network elements to
 configure the requested services on those elements.
 In this framework, specifications are expected to provide specific
 YANG modeling of service components on network elements.  There will
 be a strong 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.
 The authors of this document anticipate definitions of YANG modules
 for the network elements listed below.  Note that this list is not
 exhaustive:
 o  VRF definition, including VPN policy expression.
 o  Physical interface.
 o  IP layer (IPv4, IPv6).

Wu, et al. Standards Track [Page 121] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 o  QoS: classification, profiles, etc.
 o  Routing protocols: support of configuration of all protocols
    listed in the document, as well as routing policies associated
    with those protocols.
 o  Multicast VPN.
 o  Network address translation.
 Example of a corresponding XML snippet with a VPN site request at the
 service level, using this model:

<?xml version="1.0"?> <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc"> <vpn-profiles>

<valid-provider-identifiers>
 <qos-profile-identifier>
  <id>GOLD</id>
 </qos-profile-identifier>
 <qos-profile-identifier>
  <id>PLATINUM</id>
 </qos-profile-identifier>
</valid-provider-identifiers>

</vpn-profiles> <vpn-services>

<vpn-service>
 <vpn-id>VPN1</vpn-id>
 <vpn-service-topology>hub-spoke</vpn-service-topology>
</vpn-service>

</vpn-services> <sites>

<site>
 <site-id>Site A</site-id>
 <security>
  <encryption>
   <layer>layer3</layer>
  </encryption>
 </security>
 <locations>
  <location>
   <location-id>L1</location-id>
  </location>
 </locations>
 <site-network-accesses>
  <site-network-access>
   <site-network-access-id>1</site-network-access-id>
   <ip-connection>

Wu, et al. Standards Track [Page 122] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

    <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>
      <prefix-length>24</prefix-length>
     </addresses>
    </ipv4>
    <ipv6>
     <address-allocation-type>provider-dhcp</address-allocation-type>
    </ipv6>
   </ip-connection>
   <service>
    <svc-mtu>1514</svc-mtu>
    <svc-input-bandwidth>10000000</svc-input-bandwidth>
    <svc-output-bandwidth>10000000</svc-output-bandwidth>
   </service>
   <location-reference>L1</location-reference>
   <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>

Wu, et al. Standards Track [Page 123] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

   </entries>
  </vpn-policy>
 </vpn-policies>
</site>

</sites> </l3vpn-svc>

 In the service example above, the service component 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 snippet configuration of 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 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-network:vrf</rt:type>
<rt:description>VRF for Customer A</rt:description>
<l3vpn-network:rd>100:1546542343</l3vpn-network:rd>
<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>

Wu, et al. Standards Track [Page 124] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

  <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@2018-01-19.yang" module ietf-l3vpn-svc {

yang-version 1.1;
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;
}
import ietf-netconf-acm {
 prefix nacm;
}
organization
 "IETF L3SM Working Group";
contact
 "WG List: <mailto:l3sm@ietf.org>
  Editor:
   L3SM WG
  Chairs:
   Adrian Farrel, Qin Wu
 ";
description
"This YANG module defines a generic service configuration
model for Layer 3 VPNs. This model is common across all
vendor implementations.

Wu, et al. Standards Track [Page 125] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

Copyright (c) 2018 IETF Trust and the persons
identified as authors of the code.  All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8299; see
the RFC itself for full legal notices.";
revision 2018-01-19 {
 description
  "Revision of RFC 8049 to fix implementation issues.";
 reference
  "RFC 8299";
 }
revision 2017-01-27 {
 description
 "Initial document.";
 reference
   "RFC 8049.";
 }
/* Features */
feature cloud-access {
 description
 "Allows the VPN to connect to a CSP.";
}
feature multicast {
 description
 "Enables multicast capabilities in a VPN.";
}
feature ipv4 {
 description
 "Enables IPv4 support in a VPN.";
}
feature ipv6 {
 description
 "Enables IPv6 support in a VPN.";
}
feature lan-tag {
 description
 "Enables LAN Tag support in a VPN Policy filter.";
}
feature carrierscarrier {
 description

Wu, et al. Standards Track [Page 126] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 "Enables support of CsC.";
}
feature extranet-vpn {
 description
 "Enables support of extranet VPNs.";
}
feature site-diversity {
 description
 "Enables support of site diversity constraints.";
}
feature encryption {
 description
 "Enables support of encryption.";
}
feature qos {
 description
 "Enables support of classes of services.";
}
feature qos-custom {
 description
 "Enables support of the custom QoS profile.";
}
feature rtg-bgp {
 description
 "Enables support of the BGP routing protocol.";
}
feature rtg-rip {
 description
 "Enables support of the RIP routing protocol.";
}
feature rtg-ospf {
 description
 "Enables support of the OSPF routing protocol.";
}
feature rtg-ospf-sham-link {
 description
 "Enables support of OSPF sham links.";
}
feature rtg-vrrp {
 description
 "Enables support of the VRRP routing protocol.";
}
feature fast-reroute {
 description
 "Enables support of Fast Reroute.";
}
feature bfd {
 description

Wu, et al. Standards Track [Page 127] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 "Enables support of BFD.";
}
feature always-on {
 description
 "Enables support of the 'always-on' access constraint.";
}
feature requested-type {
 description
 "Enables support of the 'requested-type' access constraint.";
}
feature bearer-reference {
 description
 "Enables support of the 'bearer-reference' access constraint.";
}
feature target-sites {
 description
 "Enables support of the 'target-sites' match flow parameter.";
}
/* Typedefs */
typedef svc-id {
 type string;
 description
 "Defines a type of service component identifier.";
}
typedef template-id {
 type string;
 description
 "Defines a type of service template identifier.";
}
typedef address-family {
 type enumeration {
  enum ipv4 {
   description
   "IPv4 address family.";
  }
  enum ipv6 {
   description
   "IPv6 address family.";
  }
 }
 description
 "Defines a type for the address family.";
}
/* Identities */
identity site-network-access-type {
 description
 "Base identity for site-network-access type.";
}

Wu, et al. Standards Track [Page 128] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

identity point-to-point {
 base site-network-access-type;
 description
 "Identity for point-to-point connection.";
}
identity multipoint {
 base site-network-access-type;
 description
 "Identity for multipoint connection.
 Example: Ethernet broadcast segment.";
}
identity placement-diversity {
 description
 "Base identity for site placement 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.";
}
identity pop-diverse {
 base placement-diversity;
 description
 "Identity for POP diversity.";
}
identity linecard-diverse {
 base placement-diversity;
 description
 "Identity for linecard diversity.";
}
identity same-pe {
 base placement-diversity;
 description
 "Identity for having sites connected on the same PE.";
}
identity same-bearer {
 base placement-diversity;
 description
 "Identity for having sites connected using the same bearer.";
}
identity customer-application {
 description

Wu, et al. Standards Track [Page 129] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 "Base identity for customer application.";
}
identity web {
 base customer-application;
 description
 "Identity for Web application (e.g., HTTP, HTTPS).";
}
identity mail {
 base customer-application;
 description
 "Identity for mail application.";
}
identity file-transfer {
 base customer-application;
 description
 "Identity for file transfer application (e.g., FTP, SFTP).";
}
identity database {
 base customer-application;
 description
 "Identity for database application.";
}
identity social {
 base customer-application;
 description
 "Identity for social-network application.";
}
identity games {
 base customer-application;
 description
 "Identity for gaming application.";
}
identity p2p {
 base customer-application;
 description
 "Identity for peer-to-peer application.";
}
identity network-management {
 base customer-application;
 description
 "Identity for management application
 (e.g., Telnet, syslog, SNMP).";
}
identity voice {
 base customer-application;
 description
 "Identity for voice application.";
}

Wu, et al. Standards Track [Page 130] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

identity video {
 base customer-application;
 description
 "Identity for video conference application.";
}
identity embb {
 base customer-application;
 description
 "Identity for an enhanced Mobile Broadband (eMBB)
 application.  Note that an eMBB application demands
 network performance with a wide variety of
 characteristics, such as data rate, latency,
 loss rate, reliability, and many other parameters.";

} identity urllc {

 base customer-application;
 description
 "Identity for an Ultra-Reliable and Low Latency
 Communications (URLLC) application.  Note that a
 URLLC application demands network performance
 with a wide variety of characteristics, such as latency,
 reliability, and many other parameters.";
}
identity mmtc {
  base customer-application;
  description
  "Identity for a massive Machine Type
  Communications (mMTC) application.  Note that an
  mMTC application demands network performance
  with a wide variety of characteristics, such as data
  rate, latency, loss rate, reliability, and many
  other parameters.";
}
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

Wu, et al. Standards Track [Page 131] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 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 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 an NNI option A connection.";
}
identity management {
 description
 "Base identity for site management scheme.";
}
identity co-managed {
 base management;
 description
 "Base identity for co-managed site.";
}
identity customer-managed {
 base management;
 description
 "Base identity for customer-managed site.";
}
identity provider-managed {
 base management;
 description
 "Base identity for 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.";
}

Wu, et al. Standards Track [Page 132] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

identity provider-dhcp-slaac {
 base address-allocation-type;
 description
 "Provider network provides DHCP service to customer,
 as well as SLAAC.";
}
identity static-address {
 base address-allocation-type;
 description
 "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 an any-to-any IP VPN.";
}
identity spoke-role {
 base site-role;
 description
 "Spoke site in a Hub-and-Spoke IP VPN.";
}
identity hub-role {
 base site-role;
 description
 "Hub site in a Hub-and-Spoke IP VPN.";
}
identity vpn-topology {
 description
 "Base identity for VPN topology.";
}
identity any-to-any {
 base vpn-topology;
 description
 "Identity for any-to-any VPN topology.";
}
identity hub-spoke {
 base vpn-topology;
 description
 "Identity for Hub-and-Spoke VPN topology.";

Wu, et al. Standards Track [Page 133] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

}
identity hub-spoke-disjoint {
 base vpn-topology;
 description
 "Identity for Hub-and-Spoke VPN topology
 where Hubs cannot 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 bidirectional tree type.";
}
identity multicast-rp-discovery-type {
 description
 "Base identity for RP discovery type.";
}
identity auto-rp {
 base multicast-rp-discovery-type;
 description
 "Base identity for Auto-RP discovery type.";
}
identity static-rp {
 base multicast-rp-discovery-type;
 description
 "Base identity for static type.";
}
identity bsr-rp {
 base multicast-rp-discovery-type;
 description
 "Base identity for BSR discovery type.";
}
identity routing-protocol-type {
 description
 "Base identity for routing protocol type.";

Wu, et al. Standards Track [Page 134] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

}
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 LANs are directly connected
 to PE routers.";
}
identity direct {
 base routing-protocol-type;
 description
 "Identity for direct protocol 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.";
}

Wu, et al. Standards Track [Page 135] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

identity icmp {
 base protocol-type;
 description
 "ICMP protocol type.";
}
identity icmp6 {
 base protocol-type;
 description
 "ICMPv6 protocol type.";
}
identity gre {
 base protocol-type;
 description
 "GRE protocol type.";
}
identity ipip {
 base protocol-type;
 description
 "IP-in-IP protocol type.";
}
identity hop-by-hop {
 base protocol-type;
 description
 "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.";
}
identity vpn-policy-filter-type {
 description
 "Base identity for VPN Policy filter type.";
}
identity ipv4 {
  base vpn-policy-filter-type;
  description
  "Identity for IPv4 Prefix filter type.";

Wu, et al. Standards Track [Page 136] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

}
identity ipv6 {
  base vpn-policy-filter-type;
  description
  "Identity for IPv6 Prefix filter type.";

}

identity lan {
  base vpn-policy-filter-type;
  description
  "Identity for LAN Tag filter type.";

}

identity qos-profile-direction {
 description
 "Base identity for QoS profile direction.";
}
identity site-to-wan {
  base qos-profile-direction;
  description
  "Identity for Site-to-WAN direction.";
}
identity wan-to-site {
  base qos-profile-direction;
  description
  "Identity for WAN-to-Site direction.";
}
identity both {
  base qos-profile-direction;
  description
  "Identity for both WAN-to-Site direction
  and Site-to-WAN direction.";
}
/* Groupings */
grouping vpn-service-cloud-access {
 container cloud-accesses {
  if-feature cloud-access;
  list cloud-access {
   key cloud-identifier;
   leaf cloud-identifier {
    type leafref {
     path "/l3vpn-svc/vpn-profiles/"+
     "valid-provider-identifiers/cloud-identifier/id";
    }
    description
    "Identification of cloud service.
    Local administration meaning.";
   }

Wu, et al. Standards Track [Page 137] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

   choice list-flavor {
    case permit-any {
     leaf permit-any {
      type empty;
      description
      "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.  By
    default, all sites in the IP VPN MUST
    be authorized to access the cloud.";
   }
   container address-translation {
    container nat44 {
     leaf enabled {
      type boolean;
       default false;
       description
       "Controls whether or not Network address
       translation from IPv4 to IPv4 (NAT44)
       [RFC3022] is required.";
     }
     leaf nat44-customer-address {
      type inet:ipv4-address;
       description
       "Address to be used for network address
       translation from IPv4 to IPv4.  This is
       to be used if the customer is providing
       the IPv4 address.  If the customer address

Wu, et al. Standards Track [Page 138] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

       is not set, the model assumes that the
       provider will allocate the address.";
     }
     description
     "IPv4-to-IPv4 translation.";
    }
    description
    "Container for NAT.";
   }
   description
   "Cloud access configuration.";
  }
  description
  "Container for cloud access configurations.";
 }
 description
 "Grouping for VPN cloud definition.";
}
grouping multicast-rp-group-cfg {
 choice group-format {
  mandatory true;
  case singleaddress {
   leaf group-address {
    type inet:ip-address;
    description
    "A single multicast group address.";
   }
  }
  case startend {
   leaf group-start {
    type inet:ip-address;
    description
    "The first multicast group address in
    the multicast group address range.";
   }
   leaf group-end {
    type inet:ip-address;
    description
    "The last multicast group address in
    the multicast group address range.";
   }
  }
  description
  "Choice for multicast group format.";
 }
 description
 "This grouping defines multicast group or
 multicast groups for RP-to-group mapping.";

Wu, et al. Standards Track [Page 139] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

}
grouping vpn-service-multicast {
 container multicast {
  if-feature multicast;
  leaf enabled {
   type boolean;
   default false;
   description
   "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;
     leaf id {
      type uint16;
      description
      "Unique identifier for the mapping.";
     }
     container provider-managed {
      leaf enabled {
       type boolean;
       default false;
       description
       "Set to true if the Rendezvous Point (RP)
       must be a provider-managed node.  Set to false
       if it is a customer-managed node.";
      }
      leaf rp-redundancy {
       type boolean;
       default false;
       description
       "If true, a redundancy mechanism for the RP
       is required.";
      }
      leaf optimal-traffic-delivery {
       type boolean;

Wu, et al. Standards Track [Page 140] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

       default false;
       description
       "If true, the SP must ensure that
       traffic uses an optimal path.  An SP may use
       Anycast RP or RP-tree-to-SPT switchover
       architectures.";
      }
      description
      "Parameters for a provider-managed RP.";
     }
     leaf rp-address {
      when "../provider-managed/enabled = 'false'" {
       description
       "Relevant when the RP is not provider-managed.";
      }
      type inet:ip-address;
        mandatory true;
      description
      "Defines the address of the RP.
      Used if the RP is customer-managed.";
     }
     container groups {
      list group {
       key id;
       leaf id {
        type uint16;
        description
        "Identifier for the group.";
       }
       uses multicast-rp-group-cfg;
       description
       "List of multicast groups.";
      }
      description
      "Multicast groups associated with the RP.";
     }
     description
     "List of RP-to-group mappings.";
    }
    description
    "RP-to-group mappings parameters.";
   }
   container rp-discovery {
    leaf rp-discovery-type {
     type identityref {
      base multicast-rp-discovery-type;
      }
     default static-rp;

Wu, et al. Standards Track [Page 141] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

     description
     "Type of RP discovery used.";
    }
    container bsr-candidates {
      when "derived-from-or-self(../rp-discovery-type, "+
          "'l3vpn-svc:bsr-rp')" {
      description
      "Only applicable if discovery type
      is BSR-RP.";
     }
     leaf-list bsr-candidate-address {
      type inet:ip-address;
       description
       "Address of BSR candidate.";
     }
     description
     "Container for List of Customer
     BSR candidate's addresses.";
    }
    description
    "RP discovery parameters.";
   }
   description
   "RP parameters.";
  }
  description
  "Multicast global parameters for the VPN service.";
 }
 description
 "Grouping for multicast VPN definition.";
}
grouping vpn-service-mpls {
 leaf carrierscarrier {
  if-feature carrierscarrier;
   type boolean;
   default false;
   description
   "The VPN is using CsC, and so MPLS is required.";
 }
 description
 "Grouping for MPLS CsC definition.";
}
grouping customer-location-info {
 container locations {
  list location {
   key location-id;
   leaf location-id {
    type svc-id;

Wu, et al. Standards Track [Page 142] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

    description
    "Identifier for a particular 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 that
    does not have 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.";
 }
 description
 "This grouping defines customer location parameters.";
}
grouping site-group {
 container groups {
  list group {
   key group-id;
   leaf group-id {
    type string;

Wu, et al. Standards Track [Page 143] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

    description
    "Group-id the site belongs to.";
   }
   description
   "List of group-ids.";
  }
  description
  "Groups the site or site-network-access belongs to.";
 }
 description
 "Grouping definition to assign
 group-ids to site or site-network-access.";
}
grouping site-diversity {
 container site-diversity {
  if-feature site-diversity;
  uses site-group;
  description
  "Diversity constraint type.  All
  site-network-accesses will inherit
  the group values defined here.";
 }
 description
 "This grouping defines site
 diversity 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 {
      default id;
      case id {
       list group {
        key group-id;
        leaf group-id {
         type string;

Wu, et al. Standards Track [Page 144] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

         description
         "The constraint will be applied against
         this particular group-id for this site
         network access level.";
        }
        description
        "List of group-ids associated with one specific
        constraint for this site network access level.";
       }
      }
      case all-accesses {
       leaf all-other-accesses {
        type empty;
        description
        "The constraint will be applied against
        all other site network accesses of this site.";
       }
      }
      case all-groups {
       leaf all-other-groups {
        type empty;
        description
        "The constraint will be applied against
        all other groups managed by the customer.";
       }
      }
      description
      "Choice for the target flavor definition.";
     }
     description
     "The constraint will be applied against a
     Specific target, and the target can be a list
     of group-ids,all other site network accesses of
     this site, or all other groups managed by the
     customer.";
    }
    description
    "List of constraints.";
   }
   description
   "Placement constraints for this site network access.";
  }
  description
  "Diversity parameters.";
 }
 description
 "This grouping defines access diversity parameters.";
}

Wu, et al. Standards Track [Page 145] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

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.";
 }
 leaf requested-site-stop {
   type yang:date-and-time;
    description
    "Optional leaf indicating requested date and
    time when the service at a particular site is
    expected to stop.";
 }
 description
 "This grouping defines some operational
 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.";
 }
 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.";
 }
 description
 "This grouping defines some operational
 parameters.";
}
grouping flow-definition {
 container match-flow {
  leaf dscp {
   type inet:dscp;
    description
    "DSCP value.";
  }

Wu, et al. Standards Track [Page 146] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

  leaf dot1p {
   type uint8 {
    range "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;
       must "current() < ../l4-src-port-range/lower-port or "+
       "current() > ../l4-src-port-range/upper-port" {
    description
    "If l4-src-port and l4-src-port-range/lower-port and
    upper-port are set at the same time, l4-src-port
    should not overlap with l4-src-port-range.";
    }
    description
    "Match on Layer 4 src port.";
  }
  leaf-list target-sites {
    if-feature target-sites;
    type svc-id;
    description
    "Identify a site as traffic destination.";
  }
  container l4-src-port-range {
    leaf lower-port {
    type inet:port-number;

Wu, et al. Standards Track [Page 147] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

    description
    "Lower boundary for port.";
   }
   leaf upper-port {
    type inet:port-number;
    must ". >= ../lower-port" {
     description
     "Upper boundary for port.  If it
     exists, the upper boundary must be
     higher than the lower boundary.";
    }
    description
    "Upper boundary for port.";
   }
    description
    "Match on Layer 4 src port range.  When
    only the lower-port is present, it represents
    a single port.  When both the lower-port and
    upper-port are specified, it implies
    a range inclusive of both values.";
  }
  leaf l4-dst-port {
   type inet:port-number;
        must "current() < ../l4-dst-port-range/lower-port or "+
        "current() > ../l4-dst-port-range/upper-port" {
    description
    "If l4-dst-port and l4-dst-port-range/lower-port
    and upper-port are set at the same time,
    l4-dst-port should not overlap with
    l4-src-port-range.";
    }
    description
    "Match on 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.";
    }
    description

Wu, et al. Standards Track [Page 148] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

    "Upper boundary for port.  If it exists,
    upper boundary must be higher than lower
    boundary.";
   }
   description
   "Match on Layer 4 dst port range.  When only
   lower-port is present, it represents a single
   port.  When both lower-port and upper-port are
   specified, it implies a range inclusive of both
   values.";
  }
  leaf protocol-field {
   type union {
    type uint8;
    type identityref {
     base protocol-type;
    }
   }
   description
   "Match on IPv4 protocol or IPv6 Next Header field.";
  }
  description
  "Describes flow-matching criteria.";
 }
 description
 "Flow definition based on criteria.";
}
grouping site-service-basic {
 leaf svc-input-bandwidth {
   type uint64;
   units bps;
   mandatory true;
    description
    "From the customer site's perspective, the service
    input bandwidth of the connection or download
    bandwidth from the SP to the site.";
 }
 leaf svc-output-bandwidth {
  type uint64;
  units bps;
  mandatory true;
    description
    "From the customer site's perspective, the service
    output bandwidth of the connection or upload
    bandwidth from the site to the SP.";
 }
 leaf svc-mtu {
  type uint16;

Wu, et al. Standards Track [Page 149] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

  units bytes;
  mandatory true;
   description
   "MTU at service level.  If the service is IP,
   it refers to the IP MTU.  If CsC is enabled,
   the requested 'svc-mtu' leaf will refer to the
   MPLS MTU and not to the IP MTU.";
 }
 description
 "Defines basic service parameters for a site.";
}
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 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.  In this case,
    an IGP routing protocol must also be activated.";
    }
   enum bgp {
    description
    "Use BGP (as per RFC 8277) as the signalling protocol
    between the PE and the CE.
    In this case, BGP must also be configured as
    the routing protocol.";
    }
   }
   default bgp;
   description
   "MPLS signalling type.";

Wu, et al. Standards Track [Page 150] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

  }
    description
    "This container is used when the customer provides
    MPLS-based services.  This is only used in the case
    of CsC (i.e., a customer builds an MPLS service using
    an IP VPN to carry its traffic).";
 }
    description
    "Defines MPLS service parameters for 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 string;
     description
     "A description identifying the
      qos-classification-policy rule.";
    }
    choice match-type {
     default match-flow;
     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.";
    }
    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.";

Wu, et al. Standards Track [Page 151] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

   }
   description
   "Configuration of the traffic classification policy.";
  }
  container qos-profile {
   choice qos-profile {
    description
    "Choice for QoS profile.
    Can be standard profile or customized profile.";
    case standard {
     description
     "Standard QoS profile.";
     leaf profile {
      type leafref {
      path "/l3vpn-svc/vpn-profiles/valid-provider-identifiers"+
          "/qos-profile-identifier/id";
      }
      description
      "QoS profile to be used.";
     }
    }
    case custom {
     description
     "Customized QoS profile.";
      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 direction {
                 type identityref {
                  base qos-profile-direction;
                  }
                 default both;
                  description
                  "The direction to which the QoS profile
                  is applied.";
               }
                leaf rate-limit {
                 type decimal64 {
                  fraction-digits 5;
                  range "0..100";

Wu, et al. Standards Track [Page 152] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

         }
                 units percent;
                  description
                  "To be used if the class must be rate-limited.
                  Expressed as percentage of the 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.";
          }
         }
         case boundary {
          leaf latency-boundary {
           type uint16;
           units msec;
           default 400;
            description
            "The traffic class should use a path with a
            defined maximum latency.";
          }
         }
         description
         "Latency constraint on the traffic class.";
        }
        description
        "Latency constraint on the traffic 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.";
          }
         }
         case boundary {
          leaf latency-boundary {
           type uint32;
           units usec;
           default 40000;

Wu, et al. Standards Track [Page 153] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

            description
            "The traffic class should use a path with a
            defined maximum jitter.";
          }
         }
         description
         "Jitter constraint on the traffic class.";
        }
        description
        "Jitter constraint on the traffic class.";
       }
       container bandwidth {
        leaf guaranteed-bw-percent {
         type decimal64 {
                 fraction-digits 5;
                 range "0..100";
         }
         units percent;
         mandatory true;
          description
          "To be used to define the guaranteed bandwidth
          as a percentage of the available service bandwidth.";
        }
        leaf end-to-end {
         type empty;
          description
          "Used if the bandwidth reservation
          must be done on the MPLS network too.";
        }
        description
        "Bandwidth constraint on the traffic class.";
       }
       description
       "List of classes of services.";
      }
      description
      "Container for list of classes of services.";
     }
    }
   }
   description
   "QoS profile configuration.";
  }
  description
  "QoS configuration.";
 }
 description
 "This grouping defines QoS parameters for a site.";

Wu, et al. Standards Track [Page 154] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

}
grouping site-security-authentication {
 container authentication {
    description
    "Authentication parameters.";
 }
 description
 "This grouping defines authentication parameters for a site.";
}
grouping site-security-encryption {
 container encryption {
  if-feature encryption;
  leaf enabled {
   type boolean;
   default false;
    description
    "If true, traffic encryption on the connection is required.";
  }
  leaf layer {
     when "../enabled = 'true'" {
        description
        "Require a value for layer when enabled is true.";
      }
   type enumeration {
    enum layer2 {
     description
     "Encryption will occur at Layer 2.";
    }
    enum layer3 {
     description
     "Encryption will occur at Layer 3.
     For example, IPsec may be used when
     a customer requests Layer 3 encryption.";
    }
   }
   description
    "Layer on which encryption is applied.";
  }
  container encryption-profile {
   choice profile {
    case provider-profile {
     leaf profile-name {
      type leafref {
       path "/l3vpn-svc/vpn-profiles/valid-provider-identifiers"+
               "/encryption-profile-identifier/id";
      }
        description
        "Name of the SP profile to be applied.";

Wu, et al. Standards Track [Page 155] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

     }
    }
    case customer-profile {
     leaf algorithm {
      type string;
        description
        "Encryption algorithm to be used.";
     }
     choice key-type {
      default psk;
      case psk {
       leaf preshared-key {
        type string;
        description
        "Pre-Shared Key (PSK) coming from the customer.";
       }
      }
      description
      "Type of keys to be used.";
     }
    }
    description
    "Choice of encryption profile.  The encryption
    profile can be the provider profile or customer profile.";
   }
   description
   "Profile of encryption to be applied.";
  }
  description
  "Encryption parameters.";
 }
 description
 "This grouping defines encryption parameters for a site.";
}
grouping site-attachment-bearer {
 container bearer {
  container requested-type {
   if-feature requested-type;
   leaf requested-type {
    type string;
    description
    "Type of requested bearer: Ethernet, DSL,
    Wireless, etc. Operator specific.";
   }
   leaf strict {
    type boolean;
    default false;
    description

Wu, et al. Standards Track [Page 156] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

    "Defines whether requested-type is a preference
    or a strict requirement.";
   }
    description
    "Container for requested-type.";
  }
  leaf always-on {
   if-feature always-on;
   type boolean;
   default true;
    description
    "Request for an always-on access type.
    For example, this could mean no dial access type.";
  }
  leaf bearer-reference {
   if-feature bearer-reference;
   type string;
    description
    "This is an internal reference for the SP.";
  }
    description
    "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 "derived-from-or-self(../type, 'l3vpn-svc:ospf')" {
    description
    "Only applies when protocol is OSPF.";
    }
    if-feature rtg-ospf;
    leaf-list address-family {
     type address-family;
         min-elements "1";
        description

Wu, et al. Standards Track [Page 157] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

        "If OSPF is used on this site, this node
        contains a configured value.  This node
        contains at least one address family
        to be activated.";
    }
    leaf area-address {
     type yang:dotted-quad;
     mandatory true;
        description
        "Area address.";
    }
    leaf metric {
     type uint16;
     default 1;
        description
        "Metric of the PE-CE link.  It is used
        in the routing state calculation and
        path selection.";
    }
    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 to by its ID.";
      }
      leaf metric {
       type uint16;
       default 1;
        description
        "Metric of the sham link.  It is used in
        the routing state calculation and path
        selection.  The default value is set
        to 1.";
      }
        description
        "Creates a sham link with another site.";
     }
     description
     "List of sham links.";
    }
    description
    "OSPF-specific configuration.";
   }
   container bgp {

Wu, et al. Standards Track [Page 158] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

    when "derived-from-or-self(../type, 'l3vpn-svc:bgp')" {
     description
     "Only applies when protocol is BGP.";
    }
    if-feature rtg-bgp;
    leaf autonomous-system {
     type uint32;
     mandatory true;
        description
        "Customer AS number in case the customer
        requests BGP routing.";
    }
    leaf-list address-family {
     type address-family;
         min-elements "1";
        description
        "If BGP is used on this site, this node
        contains a configured value.  This node
        contains at least one address family
        to be activated.";
    }
    description
    "BGP-specific configuration.";
   }
   container static {
    when "derived-from-or-self(../type, 'l3vpn-svc:static')" {
      description
      "Only applies when protocol is static.
      BGP activation requires the SP to know
      the address of the customer peer.  When
      BGP is enabled, the 'static-address'
      allocation type for the IP connection
      MUST be used.";
    }
    container cascaded-lan-prefixes {
     list ipv4-lan-prefixes {
      if-feature ipv4;
      key "lan next-hop";
      leaf lan {
       type inet:ipv4-prefix;
       description
       "LAN prefixes.";
      }
      leaf lan-tag {
       type string;
        description
        "Internal tag to be used in VPN policies.";
      }

Wu, et al. Standards Track [Page 159] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

      leaf next-hop {
       type inet:ipv4-address;
        description
        "Next-hop address to use on the customer side.";
      }
      description
      "List of LAN prefixes for the site.";
     }
     list ipv6-lan-prefixes {
      if-feature ipv6;
      key "lan next-hop";
      leaf lan {
       type inet:ipv6-prefix;
        description
        "LAN prefixes.";
      }
      leaf lan-tag {
       type string;
       description
       "Internal tag to be used in VPN policies.";
      }
      leaf next-hop {
       type inet:ipv6-address;
        description
        "Next-hop address to use on the customer side.";
      }
      description
      "List of LAN prefixes for the site.";
     }
     description
     "LAN prefixes from the customer.";
    }
    description
    "Configuration specific to static routing.";
   }
   container rip {
    when "derived-from-or-self(../type, 'l3vpn-svc:rip')" {
     description
     "Only applies when the protocol is RIP.  For IPv4,
     the model assumes that RIP version 2 is used.";
    }
    if-feature rtg-rip;
    leaf-list address-family {
     type address-family;
         min-elements "1";
        description
        "If RIP is used on this site, this node
        contains a configured value.  This node

Wu, et al. Standards Track [Page 160] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

        contains at least one address family
        to be activated.";
    }
    description
    "Configuration specific to RIP routing.";
   }
   container vrrp {
    when "derived-from-or-self(../type, 'l3vpn-svc:vrrp')" {
     description
     "Only applies when protocol is VRRP.";
    }
    if-feature rtg-vrrp;
    leaf-list address-family {
     type address-family;
         min-elements "1";
        description
        "If VRRP is used on this site, this node
        contains a configured value.  This node contains
        at least one address family to be activated.";
    }
    description
    "Configuration specific to VRRP routing.";
   }
   description
   "List of routing protocols used on
   the site.  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;
    }
    must "not(derived-from-or-self(current(), 'l3vpn-svc:slaac') or "+
        "derived-from-or-self(current(), "+
        "'l3vpn-svc:provider-dhcp-slaac'))" {
    error-message "SLAAC is only applicable to IPv6";
    }
    description
    "Defines how addresses are allocated.

Wu, et al. Standards Track [Page 161] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

    If there is no value for the address
    allocation type, then IPv4 is not enabled.";
   }
  container provider-dhcp {
    when "derived-from-or-self(../address-allocation-type, "+
    "'l3vpn-svc:provider-dhcp')" {
    description
    "Only applies when addresses are allocated by DHCP.";
  }
    leaf provider-address {
     type inet:ipv4-address;
        description
        "Address of provider side.  If provider-address is not
        specified, then prefix length should not be specified
        either.  It also implies provider-dhcp allocation is
        not enabled.  If provider-address is specified, then
        the prefix length may or may not be specified.";
    }
    leaf prefix-length {
     type uint8 {
     range "0..32";
     }
        must "(../provider-address)" {
         error-message
         "If the prefix length is specified, provider-address
         must also be specified.";
            description
            "If the prefix length is specified, provider-address
            must also be specified.";
       }
    description
    "Subnet prefix length expressed in bits.
    If not specified, or specified as zero,
    this means the customer leaves the actual
    prefix length value to the provider.";
    }
    choice address-assign {
     default number;
     case number {
      leaf number-of-dynamic-address {
       type uint16;
       default 1;
        description
        "Describes the number of IP addresses
        the customer requires.";
      }
     }
     case explicit {

Wu, et al. Standards Track [Page 162] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

      container customer-addresses {
       list address-group {
        key "group-id";
        leaf group-id {
        type string;
        description
        "Group-id for the address range from
        start-address to end-address.";
        }
       leaf start-address {
        type inet:ipv4-address;
         description
         "First address.";
        }
       leaf end-address {
        type inet:ipv4-address;
        description
        "Last address.";
        }
        description
        "Describes IP addresses allocated by DHCP.
        When only start-address or only end-address
        is present, it represents a single address.
        When both start-address and end-address are
        specified, it implies a range inclusive of both
        addresses.  If no address is specified, it implies
        customer addresses group is not supported.";
       }
        description
        "Container for customer addresses is allocated by DHCP.";
      }
    }
        description
        "Choice for the way to assign addresses.";
    }
        description
        "DHCP allocated addresses related parameters.";
   }
container dhcp-relay {
  when "derived-from-or-self(../address-allocation-type, "+
  "'l3vpn-svc:provider-dhcp-relay')" {
    description
    "Only applies when provider is required to implement
    DHCP relay function.";
 }
leaf provider-address {
 type inet:ipv4-address;
    description

Wu, et al. Standards Track [Page 163] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

    "Address of provider side.  If provider-address is not
    specified, then prefix length should not be specified
    either.  It also implies provider-dhcp allocation is
    not enabled.  If provider-address is specified, then
    prefix length may or may not be specified.";
}
leaf prefix-length {
 type uint8 {
 range "0..32";
 }
must "(../provider-address)" {
 error-message
    "If prefix length is specified, provider-address
     must also be specified.";
    description
    "If prefix length is specified, provider-address
    must also be specified.";

}

    description
    "Subnet prefix length expressed in bits.  If not
    specified, or specified as zero, this means the
    customer leaves the actual prefix length value
    to the provider.";
}
container customer-dhcp-servers {
 leaf-list server-ip-address {
 type inet:ipv4-address;
    description
    "IP address of customer DHCP server.";
}
description
"Container for list of customer DHCP servers.";
}
description
"DHCP relay provided by operator.";

}

container addresses {
  when "derived-from-or-self(../address-allocation-type, "+
  "'l3vpn-svc:static-address')" {
  description
  "Only applies when protocol allocation type is static.";
   }
    leaf provider-address {
     type inet:ipv4-address;
        description
        "IPv4 Address List of the provider side.
        When the protocol allocation type is static,
        the provider address must be configured.";

Wu, et al. Standards Track [Page 164] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

    }
    leaf customer-address {
     type inet:ipv4-address;
        description
        "IPv4 Address of customer side.";
    }
    leaf prefix-length {
     type uint8 {
      range "0..32";
     }
    description
    "Subnet prefix length expressed in bits.
    It is applied to both provider-address
    and customer-address.";
    }
    description
    "Describes IPv4 addresses used.";
   }
   description
   "IPv4-specific parameters.";
  }
  container ipv6 {
   if-feature ipv6;
   leaf address-allocation-type {
    type identityref {
     base address-allocation-type;
    }
    description
    "Defines how addresses are allocated.
    If there is no value for the address
    allocation type, then IPv6 is
    not enabled.";
   }
  container provider-dhcp {
     when "derived-from-or-self(../address-allocation-type, "+
     "'l3vpn-svc:provider-dhcp') "+
     "or derived-from-or-self(../address-allocation-type, "+
     "'l3vpn-svc:provider-dhcp-slaac')" {
     description
     "Only applies when addresses are allocated by DHCP.";
      }
         leaf provider-address {
          type inet:ipv6-address;
          description
          "Address of the provider side.  If provider-address
          is not specified, then prefix length should not be
          specified either.  It also implies provider-dhcp

Wu, et al. Standards Track [Page 165] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

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

Wu, et al. Standards Track [Page 166] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

                leaf end-address {
                 type inet:ipv6-address;
                 description
                 "Last address.";
                 }
                description
                "Describes IP addresses allocated by DHCP.  When only
                start-address or only end-address is present, it
                represents a single address.  When both start-address
                and end-address are specified, it implies a range
                inclusive of both addresses.  If no address is
                specified, it implies customer addresses group is
                not supported.";
         }
          description
          "Container for customer addresses allocated by DHCP.";
        }
       }
        description
        "Choice for the way to assign addresses.";
       }
        description
        "DHCP allocated addresses related parameters.";
       }
  container dhcp-relay {
   when "derived-from-or-self(../address-allocation-type, "+
        "'l3vpn-svc:provider-dhcp-relay')" {
     description
     "Only applies when the provider is required
     to implement DHCP relay function.";
     }
       leaf provider-address {
        type inet:ipv6-address;
         description
         "Address of the provider side.  If provider-address is
         not specified, then prefix length should not be
         specified either.  It also implies provider-dhcp
         allocation is not enabled.  If provider address
         is specified, then prefix length may or may
         not be specified.";
         }
       leaf prefix-length {
        type uint8 {
         range "0..128";
         }
        must "(../provider-address)" {
         error-message
          "If prefix length is specified, provider-address

Wu, et al. Standards Track [Page 167] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

          must also be specified.";
         description
         "If prefix length is specified, provider-address
         must also be specified.";
          }
        description
        "Subnet prefix length expressed in bits.  If not
        specified, or specified as zero, this means the
        customer leaves the actual prefix length value
        to the provider.";
        }
   container customer-dhcp-servers {
    leaf-list server-ip-address {
     type inet:ipv6-address;
      description
      "This node contains the IP address of
      the customer DHCP server.  If the DHCP relay
      function is implemented by the
      provider, this node contains the
      configured value.";
    }
     description
     "Container for list of customer DHCP servers.";
    }
   description
   "DHCP relay provided by operator.";
   }
  container addresses {
   when "derived-from-or-self(../address-allocation-type, "+
       "'l3vpn-svc:static-address')" {
    description
    "Only applies when protocol allocation type is static.";
    }
   leaf provider-address {
    type inet:ipv6-address;
     description
     "IPv6 Address of the provider side.  When the protocol
     allocation type is static, the provider address
     must be configured.";
    }
   leaf customer-address {
    type inet:ipv6-address;
     description
     "The IPv6 Address of the customer side.";
    }
   leaf prefix-length {
    type uint8 {
     range "0..128";

Wu, et al. Standards Track [Page 168] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

    }
    description
    "Subnet prefix length expressed in bits.
    It is applied to both provider-address and
    customer-address.";
   }
   description
   "Describes IPv6 addresses used.";
   }
   description
   "IPv6-specific parameters.";
  }
  container oam {
   container bfd {
    if-feature bfd;
    leaf enabled {
     type boolean;
     default false;
     description
     "If true, BFD activation is required.";
    }
    choice holdtime {
     default fixed;
     case fixed {
      leaf fixed-value {
       type uint32;
       units msec;
        description
        "Expected BFD holdtime expressed in msec.  The customer
        may impose some fixed values for the holdtime period
        if the provider allows the customer use this function.
        If the provider doesn't allow the customer to use this
        function, the fixed-value will not be set.";
      }
     }
     case profile {
      leaf profile-name {
       type leafref {
        path "/l3vpn-svc/vpn-profiles/valid-provider-identifiers/"+
                "bfd-profile-identifier/id";
       }
       description
       "Well-known SP profile name.  The provider can propose
       some profiles to the customer, depending on the service
       level the customer wants to achieve.  Profile names
       must be communicated to the customer.";
      }
      description

Wu, et al. Standards Track [Page 169] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

      "Well-known SP profile.";
     }
     description
     "Choice for holdtime flavor.";
    }
    description
    "Container for BFD.";
   }
   description
   "Defines the Operations, Administration, and Maintenance (OAM)
   mechanisms used on the connection.  BFD is set as a fault
   detection mechanism, but the 'oam' container can easily
   be augmented by other mechanisms";
  }
  description
  "Defines connection parameters.";
 }
 description
 "This grouping defines IP connection parameters.";
}
grouping site-service-multicast {
 container multicast {
  if-feature multicast;
  leaf multicast-site-type {
   type enumeration {
    enum receiver-only {
     description
     "The site only has receivers.";
    }
    enum source-only {
     description
     "The site only has sources.";
    }
    enum source-receiver {
     description
     "The site has both sources and receivers.";
    }
   }
   default source-receiver;
   description
   "Type of multicast site.";
  }
  container multicast-address-family {
   leaf ipv4 {
    if-feature ipv4;
    type boolean;
    default false;
    description

Wu, et al. Standards Track [Page 170] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

    "Enables IPv4 multicast.";
   }
   leaf ipv6 {
    if-feature ipv6;
    type boolean;
    default false;
    description
    "Enables IPv6 multicast.";
   }
   description
   "Defines protocol to carry multicast.";
   }
  leaf protocol-type {
   type enumeration {
    enum host {
     description
     "Hosts are directly connected to the provider network.
     Host protocols such as IGMP or MLD are required.";
    }
    enum router {
     description
     "Hosts are behind a customer router.
     PIM will be implemented.";
    }
    enum both {
     description
     "Some hosts are behind a customer router, and
     some others are directly connected to the
     provider network.  Both host and routing protocols
     must be used.  Typically, IGMP and PIM will be
     implemented.";
    }
   }
   default "both";
   description
   "Multicast protocol type to be used with the customer site.";
  }
  description
  "Multicast parameters for the site.";
 }
 description
 "Multicast parameters for the site.";
}
grouping site-management {
 container management {
  leaf type {
   type identityref {
    base management;

Wu, et al. Standards Track [Page 171] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

   }
   mandatory true;
   description
   "Management type of the connection.";
  }
  description
  "Management configuration.";
 }
 description
 "Management parameters for the site.";
}
grouping site-devices {
 container devices {
  when "derived-from-or-self(../management/type, "+
  "'l3vpn-svc:provider-managed') or "+
  "derived-from-or-self(../management/type, 'l3vpn-svc:co-managed')" {
  description
  "Applicable only for provider-managed or
  co-managed device.";
 }
 list device {
  key device-id;
  leaf device-id {
   type svc-id;
   description
   "Identifier for the device.";
  }
  leaf location {
   type leafref {
    path "../../../locations/"+
    "location/location-id";
   }
   mandatory true;
   description
    "Location of the device.";
   }
  container management {
   when "derived-from-or-self(../../../management/type,"+
     "'l3vpn-svc:co-managed')" {
     description
      "Applicable only for co-managed device.";
    }
   leaf address-family {
    type address-family;
    description
    "Address family used for management.";
   }
   leaf address {

Wu, et al. Standards Track [Page 172] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

        when "(../address-family)" {
          description
          "If address-family is specified, then address should
          also be specified.  If address-family is not specified,
          then address should also not be specified.";
          }
        type inet:ip-address;
        mandatory true;
    description
    "Management address.";
    }
   description
    "Management configuration.  Applicable only for
     co-managed device.";
   }
   description
   "List of devices requested by customer.";
  }
  description
  "Device configuration.";
 }
 description
 "Grouping for device allocation.";
}
grouping site-vpn-flavor {
 leaf site-vpn-flavor {
  type identityref {
   base site-vpn-flavor;
  }
  default site-vpn-flavor-single;
  description
  "Defines the way the VPN multiplexing is done, e.g., whether
  the site belongs to a single VPN site or a multiVPN; or, in the case
  of a multiVPN, whether the logical accesses of the sites belong
  to the same set of VPNs or each logical access maps to
  different VPNs.";
 }
 description
 "Grouping for 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.";

Wu, et al. Standards Track [Page 173] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

   }
   list entries {
    key id;
    leaf id {
     type svc-id;
     description
     "Unique identifier for the policy entry.";
    }
    container filters {
     list filter {
      key type;
      ordered-by user;
      leaf type {
       type identityref {
        base vpn-policy-filter-type;
        }
       description
       "Type of VPN Policy filter.";
       }
       leaf-list lan-tag {
       when "derived-from-or-self(../type, 'l3vpn-svc:lan')" {
        description
        "Only applies when the VPN Policy filter is a
        LAN Tag filter.";
       }
        if-feature lan-tag;
        type string;
        description
        "List of 'lan-tag' items to be matched.  LAN Tag
        is an Internal tag to be used in VPN policies ";
       }
       leaf-list ipv4-lan-prefix {
       when "derived-from-or-self(../type, 'l3vpn-svc:ipv4')" {
         description
         "Only applies when VPN Policy filter is IPv4 Prefix filter.";
        }
        if-feature ipv4;
        type inet:ipv4-prefix;
        description
        "List of IPv4 prefixes as LAN Prefixes to be matched.";
       }
       leaf-list ipv6-lan-prefix {
       when "derived-from-or-self(../type, 'l3vpn-svc:ipv6')" {
       description
       "Only applies when VPN Policy filter is IPv6 Prefix filter.";
        }
        if-feature ipv6;
        type inet:ipv6-prefix;

Wu, et al. Standards Track [Page 174] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

        description
        "List of IPv6 prefixes as LAN prefixes to be matched.";
       }
        description
        "List of filters used on the site.  This list can
        be augmented.";
     }
     description
     "If a more-granular VPN attachment is necessary, filtering can
     be used.  If used, it permits the splitting of site LANs among
     multiple VPNs.  The Site LAN can be split based on either LAN
     Tag or LAN prefix.  If no filter is used, all the LANs will be
     part of the same VPNs with the same role.";
    }
    list vpn {
     key vpn-id;
     leaf vpn-id {
      type leafref {
       path "/l3vpn-svc/vpn-services/"+
        "vpn-service/vpn-id";
      }
      mandatory true;
      description
      "Reference to an IP VPN.";
     }
     leaf site-role {
      type identityref {
       base site-role;
      }
      default any-to-any-role;
      description
      "Role of the site in the IP VPN.";
     }
     description
     "List of VPNs the LAN is associated with.";
    }
    description
    "List of entries for export policy.";
   }
   description
   "List of VPN policies.";
  }
  description
  "VPN policy.";
 }
 description
 "VPN policy parameters for the site.";
}

Wu, et al. Standards Track [Page 175] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

grouping site-maximum-routes {
 container maximum-routes {
  list address-family {
   key af;
   leaf af {
    type address-family;
    description
    "Address family.";
   }
   leaf maximum-routes {
    type uint32;
    description
    "Maximum prefixes the VRF can accept
    for this address family.";
   }
   description
   "List of address families.";
  }
  description
  "Defines 'maximum-routes' for the VRF.";
 }
 description
 "Defines 'maximum-routes' for the site.";
}
grouping site-security {
 container security {
  uses site-security-authentication;
  uses site-security-encryption;
  description
  "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 attachment.";
 }
 description
 "Grouping for service parameters.";
}
grouping site-network-access-service {
 container service {
  uses site-service-basic;

Wu, et al. Standards Track [Page 176] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

  uses site-service-qos-profile;
  uses site-service-mpls;
  uses site-service-multicast;
  description
  "Service parameters on the 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 the local VPN want to access.";
   }
   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.  In the any-to-any VPN
    service topology, the local sites must have the same role, which
    will be 'any-to-any-role'.  In the Hub-and-Spoke VPN service
    topology or the Hub-and-Spoke disjoint VPN service topology,
    the local sites must have a Hub role or a Spoke role.";
   }
   description
   "List of extranet VPNs or target VPNs the local VPN is
   attached to.";
  }
  description
  "Container for extranet VPN configuration.";
 }
 description
 "Grouping for extranet VPN configuration.
 This provides an easy way to interconnect
 all sites from two VPNs.";
}
grouping site-attachment-availability {
 container availability {
  leaf access-priority {
   type uint32;

Wu, et al. Standards Track [Page 177] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

   default 100;
   description
   "Defines the priority for the access.
   The higher the access-priority value,
   the higher the preference of the
   access will be.";
  }
  description
  "Availability parameters (used for multihoming).";
 }
 description
 "Defines availability 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 "../../../../"+
       "vpn-policies/vpn-policy/"+
       "vpn-policy-id";
     }
     description
     "Reference to a VPN policy.  When referencing VPN
     policy for attachment, the vpn-policy-id must be
     configured.";
    }
   }
   case vpn-id {
    leaf vpn-id {
     type leafref {
      path "/l3vpn-svc/vpn-services"+
       "/vpn-service/vpn-id";
     }
     description
     "Reference to an IP VPN.  Referencing a vpn-id provides
     an easy way to attach a particular logical access to
     a VPN.  In this case, vpn-id must be configured.";
    }
    leaf site-role {
     type identityref {
      base site-role;
     }
     default any-to-any-role;
     description
     "Role of the site in the IP VPN.  When referencing a vpn-id,
     the site-role setting must be added to express the role of

Wu, et al. Standards Track [Page 178] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

     the site in the target VPN service topology.";
    }
   }
   mandatory true;
   description
   "Choice for VPN attachment flavor.  A choice is implemented
   to allow the user to choose the flavor that provides the
   best fit.";
  }
  description
  "Defines VPN attachment of a site.";
 }
 description
 "Defines the VPN attachment rules for
 a site's logical access.";
}
grouping vpn-profile-cfg {
 container valid-provider-identifiers {
  list cloud-identifier {
   if-feature cloud-access;
   key id;
   leaf id {
    type string;
    description
    "Identification of cloud service.
    Local administration meaning.";
   }
   description
   "List for Cloud Identifiers.";
  }
  list encryption-profile-identifier {
   key id;
   leaf id {
    type string;
    description
    "Identification of the SP encryption profile
    to be used.  Local administration meaning.";
   }
   description
   "List for encryption profile identifiers.";
  }
  list qos-profile-identifier {
   key id;
   leaf id {
    type string;
    description
    "Identification of the QoS Profile to be used.
    Local administration meaning.";

Wu, et al. Standards Track [Page 179] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

   }
   description
   "List for QoS Profile Identifiers.";
  }
  list bfd-profile-identifier {
   key id;
   leaf id {
    type string;
    description
    "Identification of the SP BFD Profile to be used.
    Local administration meaning.";
   }
   description
   "List for BFD Profile identifiers.";
  }
    nacm:default-deny-write;
    description
    "Container for Valid Provider Identifies.";
 }
  description
  "Grouping for VPN Profile configuration.";
}
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 that actually uses the VPN service.
  In the case that any intermediary (e.g., Tier-2 provider
  or partner) sells the VPN service to their end user
  on behalf of the original service provider (e.g., Tier-1
  provider), the original service provider may require the
  customer name to provide smooth activation/commissioning
  and operation for the service.";
 }
 leaf vpn-service-topology {
  type identityref {
   base vpn-topology;
  }
  default any-to-any;
  description
  "VPN service topology.";
 }
 uses vpn-service-cloud-access;

Wu, et al. Standards Track [Page 180] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 uses vpn-service-multicast;
 uses vpn-service-mpls;
 uses vpn-extranet;
 description
 "Grouping for 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 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.,
  point-to-point or multipoint.";
 }
 choice location-flavor {
  case location {
   when "derived-from-or-self(../../management/type, "+
    "'l3vpn-svc:customer-managed')" {
    description
    "Applicable only for customer-managed device.";
   }
   leaf location-reference {
    type leafref {
     path "../../../locations/location/location-id";
    }
    description
    "Location of the site-network-access.";
   }
  }
  case device {

Wu, et al. Standards Track [Page 181] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

   when "derived-from-or-self(../../management/type, "+
    "'l3vpn-svc:provider-managed') or "+
    "derived-from-or-self(../../management/type, "+
    "'l3vpn-svc:co-managed')" {
    description
    "Applicable only for provider-managed or co-managed device.";
   }
   leaf device-reference {
    type leafref {
     path "../../../devices/device/device-id";
    }
    description
    "Identifier of CE to use.";
   }
  }
  mandatory true;
  description
  "Choice of how to describe the 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 configuration.";
}
/* Main blocks */
container l3vpn-svc {
 container vpn-profiles {
  uses vpn-profile-cfg;
   description
   "Container for VPN Profiles.";
 }
 container vpn-services {
  list vpn-service {
   key vpn-id;
   uses vpn-svc-cfg;
   description
   "List of VPN services.";
  }
  description
  "Top-level container for the VPN services.";
 }
 container sites {

Wu, et al. Standards Track [Page 182] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

  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.";
     }
     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.";
 }
 description
 "Main container for L3VPN service configuration.";
}

} <CODE ENDS>

Wu, et al. Standards Track [Page 183] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

10. Security Considerations

 The YANG module specified in this document defines a schema for data
 that is designed to be accessed via network management protocols such
 as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF layer
 is the secure transport layer, and the mandatory-to-implement secure
 transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
 is HTTPS, and the mandatory-to-implement secure transport is TLS
 [RFC5246].
 The NETCONF access control model [RFC6536]provides the means to
 restrict access for particular NETCONF or RESTCONF users to a
 preconfigured subset of all available NETCONF or RESTCONF protocol
 operations and content.
 There are a number of data nodes defined in this YANG module that are
 writable/creatable/deletable (i.e., config true, which is the
 default).  These data nodes may be considered sensitive or vulnerable
 in some network environments.  Write operations (e.g., edit-config)
 to these data nodes without proper protection can have a negative
 effect on network operations.  These are the subtrees and data nodes
 and their sensitivity/vulnerability:
 o  /l3vpn-svc/vpn-services/vpn-service
    The entries in the list above include the whole vpn service
    configurations which the customer subscribes, and indirectly
    create or modify the PE and CE device configurations.  Unexpected
    changes to these entries could lead to service disruption and/or
    network misbehavior.
 o  /l3vpn-svc/sites/site
    The entries in the list above include the customer site
    configurations.  As above, unexpected changes to these entries
    could lead to service disruption and/or network misbehavior.
 Some of the readable data nodes in this YANG module may be considered
 sensitive or vulnerable in some network environments.  It is thus
 important to control read access (e.g., via get, get-config, or
 notification) to these data nodes.  These are the subtrees and data
 nodes and their sensitivity/vulnerability:
 o  /l3vpn-svc/vpn-services/vpn-service
 o  /l3vpn-svc/sites/site

Wu, et al. Standards Track [Page 184] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 The entries in the lists above include customer-proprietary or
 confidential information, e.g., customer-name, site location, what
 service the customer subscribes.
 The data model defines some security parameters than can be extended
 via augmentation as part of the customer service request; those
 parameters are described in Section 6.9.

11. IANA Considerations

 IANA has assigned a new URI from the "IETF XML Registry" [RFC3688].
           URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc
           Registrant Contact: The IESG
           XML: N/A; the requested URI is an XML namespace.
 IANA has recorded a YANG module name in the "YANG Module Names"
 registry [RFC6020] as follows:
         Name: ietf-l3vpn-svc
         Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc
         Prefix: l3vpn-svc
         Reference: RFC 8299
 IANA previously assigned the URI and YANG module as described in
 [RFC8049].  IANA has updated the references for these entries to
 refer to this document.

12. References

12.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <https://www.rfc-editor.org/info/rfc2119>.
 [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
            Address Translator (Traditional NAT)", RFC 3022,
            DOI 10.17487/RFC3022, January 2001,
            <https://www.rfc-editor.org/info/rfc3022>.
 [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
            DOI 10.17487/RFC3688, January 2004,
            <https://www.rfc-editor.org/info/rfc3688>.

Wu, et al. Standards Track [Page 185] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
            Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
            2006, <https://www.rfc-editor.org/info/rfc4364>.
 [RFC4577]  Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the
            Provider/Customer Edge Protocol for BGP/MPLS IP Virtual
            Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577,
            June 2006, <https://www.rfc-editor.org/info/rfc4577>.
 [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
            Address Autoconfiguration", RFC 4862,
            DOI 10.17487/RFC4862, September 2007,
            <https://www.rfc-editor.org/info/rfc4862>.
 [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
            (TLS) Protocol Version 1.2", RFC 5246,
            DOI 10.17487/RFC5246, August 2008,
            <https://www.rfc-editor.org/info/rfc5246>.
 [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
            the Network Configuration Protocol (NETCONF)", RFC 6020,
            DOI 10.17487/RFC6020, October 2010,
            <https://www.rfc-editor.org/info/rfc6020>.
 [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
            and A. Bierman, Ed., "Network Configuration Protocol
            (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
            <https://www.rfc-editor.org/info/rfc6241>.
 [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
            Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
            <https://www.rfc-editor.org/info/rfc6242>.
 [RFC6513]  Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
            BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
            2012, <https://www.rfc-editor.org/info/rfc6513>.
 [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
            Protocol (NETCONF) Access Control Model", RFC 6536,
            DOI 10.17487/RFC6536, March 2012,
            <https://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,
            <https://www.rfc-editor.org/info/rfc7950>.

Wu, et al. Standards Track [Page 186] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

 [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
            Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
            <https://www.rfc-editor.org/info/rfc8040>.
 [RFC8049]  Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data
            Model for L3VPN Service Delivery", RFC 8049,
            DOI 10.17487/RFC8049, February 2017,
            <https://www.rfc-editor.org/info/rfc8049>.
 [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
            2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
            May 2017, <https://www.rfc-editor.org/info/rfc8174>.

12.2. Informative References

 [ACL-YANG] Jethanandani, M., Huang, L., Agarwal, S., and D. Blair,
            "Network Access Control List (ACL) YANG Data Model", Work
            in Progress, draft-ietf-netmod-acl-model-14, October 2017.
 [RFC4026]  Andersson, L. and T. Madsen, "Provider Provisioned Virtual
            Private Network (VPN) Terminology", RFC 4026,
            DOI 10.17487/RFC4026, March 2005,
            <https://www.rfc-editor.org/info/rfc4026>.
 [RFC4110]  Callon, R. and M. Suzuki, "A Framework for Layer 3
            Provider-Provisioned Virtual Private Networks (PPVPNs)",
            RFC 4110, DOI 10.17487/RFC4110, July 2005,
            <https://www.rfc-editor.org/info/rfc4110>.
 [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
            "Multiprotocol Extensions for BGP-4", RFC 4760,
            DOI 10.17487/RFC4760, January 2007,
            <https://www.rfc-editor.org/info/rfc4760>.
 [RFC8277]  Rosen, E., "Using BGP to Bind MPLS Labels to Address
            Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
            <https://www.rfc-editor.org/info/rfc8277>.

Wu, et al. Standards Track [Page 187] RFC 8299 YANG Data Model for L3VPN Service Delivery January 2018

Acknowledgements

 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 provided useful review to this document.
 Jan Lindblad reviewed RFC 8049 and found some bugs, and his thorough
 YANG Doctor review on the YANG Module is valuable input.  David Ball
 also provided a second review on RFC 8049.
 Many thanks to these people.

Contributors

 The authors would like to thank Rob Shakir for his major
 contributions to the initial modeling and use cases.
 Adrian Farrel prepared the editorial revisions for this document.

Authors' Addresses

 Qin Wu (editor)
 Huawei Technologies
 Email: bill.wu@huawei.com
 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

Wu, et al. Standards Track [Page 188]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8299.txt · Last modified: 2018/01/20 00:33 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki