OPSAWG Working Group                                             R. Even
Internet-Draft                                                     B. Wu
Intended status: Standards Track                                   Q. Wu
Expires: September 9, 2019                                        Huawei
                                                                Y. Cheng
                                                            China Unicom
                                                           March 8, 2019


           YANG Data Model for Composed VPN Service Delivery
                draft-evenwu-opsawg-yang-composed-vpn-03

Abstract

   This document defines a YANG data model that can be used by a network
   operator to configure a VPN service that spans multiple
   administrative domains and that is constructed from component VPNs in
   each of those administrative domains.  The component VPNs may be
   L2VPN or L3VPN or a mixture of the two.  This model is intended to be
   instantiated at the management system to deliver the end to end
   service (i.e., performing service provision and activation functions
   at different levels through a unified interface).

   The model is not a configuration model to be used directly on network
   elements.  This model provides an abstracted common view of VPN
   service configuration components segmented at different layer and
   administrative domain.  It is up to a management system to take this
   as an input and generate specific configurations models to configure
   the different network elements within each administrative domain to
   deliver the service.  How configuration of network elements is done
   is out of scope of the document.

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 9, 2019.



Even, et al.            Expires September 9, 2019               [Page 1]


Internet-Draft           Composed VPN YANG Model              March 2019


Copyright Notice

   Copyright (c) 2019 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.1.  Requirements Language . . . . . . . . . . . . . . . .   4
     1.2.  Tree diagram  . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Service Model Usage . . . . . . . . . . . . . . . . . . . . .   6
   4.  The Composed VPN Service Model  . . . . . . . . . . . . . . .   7
     4.1.  VPN Service Types . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Composed VPN Physical Network Topology  . . . . . . . . .   7
   5.  Design of the Data Model  . . . . . . . . . . . . . . . . . .   9
     5.1.  VPN Hierarchy . . . . . . . . . . . . . . . . . . . . . .  15
     5.2.  Access Point(AP)  . . . . . . . . . . . . . . . . . . . .  16
       5.2.1.  AP peering with CE  . . . . . . . . . . . . . . . . .  16
       5.2.2.  AP peering for inter-domains connection . . . . . . .  17
   6.  Composed VPN YANG Module  . . . . . . . . . . . . . . . . . .  19
   7.  Segment VPN YANG Module . . . . . . . . . . . . . . . . . . .  21
   8.  Service Model Usage Example . . . . . . . . . . . . . . . . .  53
   9.  Interaction with other YANG models  . . . . . . . . . . . . .  56
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  57
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  58
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  58
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  58
     12.2.  Informative References . . . . . . . . . . . . . . . . .  60
   Appendix A.  Acknowledges . . . . . . . . . . . . . . . . . . . .  60
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  60

1.  Introduction

   In some cases, a VPN service needs to span different administrative
   domains.  This will usually arise when there are internal
   administrative boundaries within a single Service Provider's (SP's)



Even, et al.            Expires September 9, 2019               [Page 2]


Internet-Draft           Composed VPN YANG Model              March 2019


   network.  The boundaries may reflect geographic dispersal or
   functional decomposition, e.g., access, metro, backhaul, core, and
   data center.

   In particular, the different domains could deploy Layer 2 or Layer 3
   technologies or both, and could establish layer-dependent
   connectivity services.  For example, some SPs offer a L2VPN service
   in the metro access network and extend it across the core network as
   an IP VPN to provide end-to-end BGP IP VPN services to their
   enterprise customers.

   Some SPs integrate Mobile Backhaul Network and Core networks to
   provide mobile broadband services.  These require stitching multiple
   layer-dependent connectivity services at different administrative
   domain boundaries.

   This document defines a YANG data model that can be used by a network
   operator to construct an end-to-end service across multiple
   administrative domains.  This service is delivered by provisioning
   VPN services utilising Layer 2 or Layer 3 technologies in each
   domain.

   This model is intended to be instantiated at the management system to
   deliver the overall service per [RFC8309].  It is not a configuration
   model to be used directly on network elements.  This model provides
   an abstracted common view of VPN service configuration components
   segmented at different layers and administrative domains.  It is up
   to a management system to take this as an input and generate specific
   configurations models to configure the different network elements
   within each administrative domain to deliver the service.  How
   configuration of network elements is done is out of scope of the
   document.  END

1.1.  Terminology

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

   o  client

   o  server

   o  configuration data

   o  state data

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



Even, et al.            Expires September 9, 2019               [Page 3]


Internet-Draft           Composed VPN YANG Model              March 2019


   o  augment

   o  data model

   o  data node

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

1.1.1.  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] and [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.  Tree diagram

   Tree diagrams used in this document follow the notation defined in
   [RFC8340].

2.  Definitions

   This document uses the following terms:

   Service Provider (SP):   The organization (usually a commercial
      undertaking) responsible for operating the network that offers VPN
      services to clients and customers.

   Customer Edge (CE) Device:   Equipment that is dedicated to a
      particular customer and is directly connected 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.  The CE devices can be routers, bridges,
      switches, or hosts.

   Provider Edge (PE) Device:  Equipment managed by the SP that can
      support multiple VPNs for different customers, and is directly
      connected 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.

   Administrative Domain:  A collection of End Systems, Intermediate
      Systems, and subnetworks operated by a single organization or
      administrative authority.  The components which make up the domain
      are assumed to interoperate with a significant degree of mutual



Even, et al.            Expires September 9, 2019               [Page 4]


Internet-Draft           Composed VPN YANG Model              March 2019


      trust among themselves, but interoperate with other Administrative
      Domains in a mutually suspicious manner [RFC1136].

      A group of hosts, routers, and networks operated and managed by a
      single organization.  Routing within an Administrative Domain is
      based on a consistent technical plan.  An Administrative Domain is
      viewed from the outside, for purposes of routing, as a cohesive
      entity, of which the internal structure is unimportant.
      Information passed by other Administrative Domains is trusted less
      than information from one's own Administrative Domain.

      Administrative Domains can be organized into a loose hierarchy
      that reflects the availability and authoritativeness of routing
      information.  This hierarchy does not imply administrative
      containment, nor does it imply a strict tree topology.

   Routing Domain:  A set of End Systems and Intermediate Systems which
      operate according to the same routing procedures and which is
      wholly contained within a single Administrative Domain [RFC1136].

      A Routing Domain is a set of Intermediate Systems and End Systems
      bound by a common routing procedure; namely: they are using the
      same set of routing metrics, they use compatible metric
      measurement techniques, they use the same information distribution
      protocol, and they use the same path computation algorithm" An
      Administrative Domain may contain multiple Routing Domains.  A
      Routing Domain may never span multiple Administrative Domains.

      An Administrative Domain may consist of only a single Routing
      Domain, in which case they are said to be Congruent.  A congruent
      Administrative Domain and Routing Domain is analogous to an
      Internet Autonomous System.

   Access point(AP):  Describe an VPN's end point characteristics and
      its reference to a Termination Point (TP) of the Provider Edge
      (PE) Node; used as service access point for connectivity service
      segment in the end-to-end manner and per administrative domain.

   Site:  Represent a connection of a customer office to one or more VPN
      services and contain a list of network accesses associated with
      the site.  Each network access can connect to different VPN
      service.

   Segment VPN  Describe generic information about a VPN in a single
      administrative domain, and specific information about APs that
      connect the Segment VPN to sites or to other Segment VPNs.





Even, et al.            Expires September 9, 2019               [Page 5]


Internet-Draft           Composed VPN YANG Model              March 2019


   Composed VPN  Describe generic end-to-end information about a VPN
      that spans multiple administrative domains, and specific customer-
      facing information about APsconnecting to each site.

3.  Service Model Usage

                                   +
       Customer Facing Interface   |  L2SM or L3SM
                            +------v----------------+
                            | Service orchestration |
                            +------+----------------+
                                   | Composed VPN
                            +------v---------------+
                            | Network Orchestrator |
                            +----+---+-------------+
                                 |   |
                       +---------+   +-----------+
                       |                         |
                +------+--------+         +------+---------+
                |Config manager1|         | Config manager2|
                +------+--------+         +------+---------+
                       |                         |
             +---------+-----------+  +----------+----------+
             |      AS1 L2VPN      |  |      AS2  L3VPN     |
  +-------+  | +------+   +------+ |  | +------+   +------+ |  +-------+
  | Site1 +----+ PE11 +---+ PE12 +------+ PE21 +---+ PE22 +----+ Site2 |
  +-------+  | +------+   +------+ |  | +------+   +------+ |  +-------+
             +---------------------+  +---------------------+

                       Figure 1: Service Model Usage

   In the above use case, the network orchestrator controls and manages
   the two distinct network domains, each controlled or managed by their
   own management system or domain controller.  There are two typical
   ways to deploy the composed VPN model:

   One typical scenario would be to use the model as an independent
   model.  The orchestration layer could use composed VPN model as an
   input, and translate it to segmented VPN model for each
   administrative domain.  And the domain management system could
   further configure network elements based on configuration obtained
   from the segment VPN.

   The other scenario is to use customer facing model such as L3SM
   service model as an input for the service orchestration layer that
   will be responsible for translating the parameters of VPN and site in
   L3SM model to the corresponding parameters of the composed VPN model,
   then with extra provisioning parameters added ,the composed VPN model



Even, et al.            Expires September 9, 2019               [Page 6]


Internet-Draft           Composed VPN YANG Model              March 2019


   can be further broken down into per domain segmented VPN model and
   additional Access point configuration.

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

4.  The Composed VPN Service Model

   A composed VPN represents an end-to-end IP or Ethernet connectivity
   between the access points of PE where the AP can interconnect with
   the enterprise customer's network or other types of overlay network.
   The Composed VPN model provides a common understanding of how the
   corresponding composed VPN service is to be deployed in an end to end
   manner over the multi-domain infrastructure.

   This document presents the Composed VPN Service Delivery Model using
   the YANG data modeling language [RFC7950] as a formal language that
   is both human-readable and parsable by software for use with
   protocols such as NETCONF [RFC6241] and RESTCONF [RFC8040].

4.1.  VPN Service Types

   From a technology perspective, a Composed VPN can be classified into
   three categories based on the domain specific VPN types including
   L2VPN and L3VPN, see Figure 2.  And in each category, the
   interworking option may vary depending on the inter-domain
   technology, such as IP or MPLS forwarding.  In some cases, the number
   of transit domain can be zero or multiple.

   +----------+----------+---------+  +--------+---------------+
   | Composed | Domain 1 | Domain 2|..|Domain N| Interworking  |
   |   VPN    |  (source)|(transit)|  | (dest) |   Option      |
   |----------+----------+---------+  +--------+---------------+
   |L3VPN     | L2VPN    | L2VPN   |..|L3VPN   |  Option A     |
   |----------+----------+---------+  +--------+---------------+
   |L3VPN     | L3VPN    | L3VPN   |..|L3VPN   |  OptionA/B/C  |
   |----------+----------+---------+  +--------+---------------+
   |L2VPN     | L2VPN    | L2VPN   |..|L2VPN   |  OptionA/B/C  |
   +----------+----------+---------+  +--------+---------------+

                   Figure 2: Composed VPN classification

4.2.  Composed VPN Physical Network Topology

   Figure 3 describes a scenario where connectivity in the form of an
   L3VPN is provided across a Mobile Backhaul Network.  The network has
   two ASes: connectivity across AS A is achieved with an L2VPN, and



Even, et al.            Expires September 9, 2019               [Page 7]


Internet-Draft           Composed VPN YANG Model              March 2019


   across AS B an L3VPN.  The ASes are interconnected, and the composed
   VPN is achieved by interconnecting the L2VPN with the L3VPN.

 +---------------------------Composed VPN: L3VPN 1----------------------+
 |                            (AP 1,2,7,8)                              |
 |                                                                      |
 |                                                                      |
 |                                                                      |
 |+---SegVPN:VLL1.1(AP 1,3)---+             +------ SegVPN:L3VPN1.3 ----+
 |           VLL1.2(AP 2,4)   |             |       (AP 5,6,7,8)        |
 |                            |             |                           |
 |                            |             |                           |
 |    -------------------     |             |     -------------------   |
 |   /       AS A         |   |Inter-AS link|   |        AS B           |
 |  |                     |   |             |   |              +------+ |
 |  +------+              |   |             |   |              |PE2    /-\
 /-\|  PE1 |          ++++++++|             |++++++++          |      |AP8|
|AP1|      |          + ASBRA /-\          /-\ ASBRB+          |       \-/
 \-/|      |          +      |AP3  _______|AP5      +          +------+
    +------+          +       \-/          \-/      +                 |
    |                 +       /-\  _______ /-\      +                 |
    |                 +      |AP4         |AP6      +                 |
    +------+          +++++++ \-/          \-/+++++++          +------+
 /-\|      |              |                     |              |       /-\
|AP2|PE4   |              |                     |              |PE3   |AP7|
 \-/|      |              |                     |              |       \-/
    +------+              |                     |              +------+
     \                   /                       \                   /
      -------------------                         -------------------

                Figure 3: Mobile Backhaul Network Scenario

   The Composed VPN is a service that provides connectivity between AP1,
   AP2, AP7 and AP8.  As the APs of the VPN are spanning the two
   domains, the ASBR A and B and their associated links are required to
   be identified.  Based on the decomposition, two Segment VPN could be
   constructed to provide per domain connections.  Segment VPN 1.1 and
   Segment VPN 1.2 are connections between AP 1,2,3,4 in the domain A of
   access metro network, which are L2VPN.  Segment VPN 1.3 is the
   connection between AP 5,6,7,8 in the core network, which is L3VPN.
   The ASBR A and B at the edge of the access metro network is
   performing the VPN stitching between Layer 2 VPN and Layer 3 VPN
   using the technology such as bridging or other interconnection
   technology.

   The operator can predefine several VPN provisioning policies based on
   the offered business.  The policy description may include the naming,
   path selection, VPN concatenation rules,and resource pools, such as



Even, et al.            Expires September 9, 2019               [Page 8]


Internet-Draft           Composed VPN YANG Model              March 2019


   route target, route distinguisher.  How VPN provision policies
   configuration of network elements is done is out of scope of the
   document.

5.  Design of the Data Model

   The idea of the composed VPN model is to decompose an end-to-end
   L2VPN or L3VPN service across multiple administrative domains into
   point-to-point VPN segments or multi-point VPN segments in each
   administrative domain, and to stich these segments together by using
   different interworking options.  Therefore, a complete composed VPN
   instance consists of:

   o  One composed VPN with corresponding composed VPN set of parameter

   o  Two or more APs, each with a corresponding set of AP parameters

   o  One or more segment VPN with corresponding segment VPN set of
      parameter

   Similar to the L3SM [RFC8299] and L2SM [RFC8466] modelling structure,
   the composed VPN model consists of two main components, the VPN
   component and the AP component.

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

module: ietf-composed-vpn-svc
  +--rw composed-vpns
     +--rw composed-vpn* [vpn-id]
        +--rw vpn-id           yang:uuid
        +--rw vpn-name?        string
        +--rw customer-name?   yang:uuid
        +--rw topo?            svpn:vpn-topology
        +--rw service-type?    svpn:service-type
        +--rw tunnel-type?     svpn:tunnel-type
        +--rw admin-state?     svpn:admin-state
        +--ro oper-State?      svpn:oper-state
        +--ro sync-state?      svpn:sync-state
        +--rw start-time?      yang:date-and-time
        +--rw segment-vpn* [vpn-id]
        |  +--rw vpn-id          yang:uuid
        |  +--rw vpn-name?       string
        |  +--rw service-type?   service-type
        |  +--rw topo?           vpn-topology
        |  +--rw tunnel-type?    tunnel-type
        |  +--rw admin-state?    admin-state
        |  +--ro oper-state?     oper-state
        |  +--ro sync-state?     sync-state



Even, et al.            Expires September 9, 2019               [Page 9]


Internet-Draft           Composed VPN YANG Model              March 2019


        |  +--rw access-point* [tp-id]
        |     +--rw tp-id                               yang:uuid
        |     +--rw tp-common-attribute
        |     |  +--rw tp-id?               yang:uuid
        |     |  +--rw tp-name?             string
        |     |  +--rw node-id?             yang:uuid
        |     |  +--rw access-point-type?   access-point-type
        |     |  +--rw inter-as-option?     enumeration
        |     |  +--rw topology-role?       topology-role
        |     +--rw peer-remote-node
        |     |  +--rw remote-id?           yang:uuid
        |     |  +--rw location?            string
        |     |  +--rw remote-tp-address?   inet:ip-address
        |     |  +--rw remote-node-id?      yang:uuid
        |     |  +--rw remote-tp-id?        yang:uuid
        |     +--rw tp-connection-specific-attribute
        |     |  +--rw connection* [connection-class]
        |     |  |  +--rw connection-class    layer-rate
        |     |  |  +--rw (connection-type)?
        |     |  |     +--:(lr-eth)
        |     |  |     |  +--rw eth
        |     |  |     |     +--rw access-type?   eth-encap-type
        |     |  |     |     +--rw (accessVlanValue)?
        |     |  |     |     |  +--:(qinq)
        |     |  |     |     |  |  +--rw qinq
        |     |  |     |     |  |     +--rw cvlan*   uint64
        |     |  |     |     |  |     +--rw svlan?   uint64
        |     |  |     |     |  +--:(dot1q)
        |     |  |     |     |     +--rw dot1q
        |     |  |     |     |        +--rw dot1q*   uint64
        |     |  |     |     +--rw vlan-action?   ethernet-action
        |     |  |     |     +--rw action?        string
        |     |  |     +--:(lr-ip)
        |     |  |     |  +--rw ip
        |     |  |     |     +--rw ip-address?   inet:ip-address
        |     |  |     |     +--rw mtu?          uint64
        |     |  |     +--:(lr-pw)
        |     |  |        +--rw pw
        |     |  |           +--rw control-word?   boolean
        |     |  |           +--rw vlan-action?    pwtagmode
        |     |  +--rw security-attribute
        |     |  |  +--rw security
        |     |  |     +--rw authentication
        |     |  |     +--rw encryption {encryption}?
        |     |  |        +--rw enabled?               boolean
        |     |  |        +--rw layer?                 enumeration
        |     |  |        +--rw algorithm?             string
        |     |  |        +--rw (key-type)?



Even, et al.            Expires September 9, 2019              [Page 10]


Internet-Draft           Composed VPN YANG Model              March 2019


        |     |  |           +--:(psk)
        |     |  |              +--rw preshared-key?   string
        |     |  +--rw qos-attribute
        |     |  |  +--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)?
        |     |  |     |     |  +--:(match-flow)
        |     |  |     |     |  |  +--rw match-flow
        |     |  |     |     |  |     +--rw dscp?                inet:dscp
        |     |  |     |     |  |     +--rw exp?                 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 peer-remote-node*    string
        |     |  |     |     |  |     +--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 src-mac?             yang:mac-address
        |     |  |     |     |  |     +--rw dst-mac?             yang:mac-address
        |     |  |     |     |  |     +--rw protocol-field?      union
        |     |  |     |     |  +--:(match-application)
        |     |  |     |     |     +--rw match-application?   identityref
        |     |  |     |     +--rw target-class-id?           string
        |     |  |     +--rw qos-profile
        |     |  |        +--rw (qos-profile)?
        |     |  |           +--:(standard)
        |     |  |           |  +--rw profile?   string
        |     |  |           +--:(custom)
        |     |  |              +--rw classes {qos-custom}?
        |     |  |                 +--rw class* [class-id]
        |     |  |                    +--rw class-id      string
        |     |  |                    +--rw direction?    identityref
        |     |  |                    +--rw rate-limit?   decimal64
        |     |  |                    +--rw latency
        |     |  |                    |  +--rw (flavor)?
        |     |  |                    |     +--:(lowest)



Even, et al.            Expires September 9, 2019              [Page 11]


Internet-Draft           Composed VPN YANG Model              March 2019


        |     |  |                    |     |  +--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 protection-attribute
        |     |     +--rw access-priority?   uint32
        |     +--rw routing-protocol* [type]
        |        +--rw type            protocol-type
        |        +--rw (para)?
        |           +--:(static)
        |           |  +--rw static* [index]
        |           |     +--rw index               uint32
        |           |     +--rw dest-cidr?          string
        |           |     +--rw egress-tp?          yang:uuid
        |           |     +--rw route-preference?   string
        |           |     +--rw next-hop?           inet:ip-address
        |           +--:(bgp)
        |              +--rw bgp* [index]
        |                 +--rw index                uint32
        |                 +--rw autonomous-system    uint32
        |                 +--rw address-family*      address-family
        |                 +--rw max-prefix?          int32
        |                 +--rw peer-address?        inet:ip-address
        |                 +--rw crypto-algorithm     identityref
        |                 +--rw key-string
        |                    +--rw (key-string-style)?
        |                       +--:(keystring)
        |                       |  +--rw keystring?            string
        |                       +--:(hexadecimal) {hex-key-string}?
        |                          +--rw hexadecimal-string?   yang:hex-string
        +--rw access-point* [tp-id]
           +--rw tp-id                               yang:uuid
           +--rw tp-name?             string
           +--rw node-id?             yang:uuid
           +--rw access-point-type?   access-point-type
           +--rw inter-as-option?     enumeration
           +--rw topology-role?       topology-role
           +--rw peer-remote-node
           |  +--rw remote-id?           yang:uuid
           |  +--rw location?            string



Even, et al.            Expires September 9, 2019              [Page 12]


Internet-Draft           Composed VPN YANG Model              March 2019


           |  +--rw remote-tp-address?   inet:ip-address
           |  +--rw remote-node-id?      yang:uuid
           |  +--rw remote-tp-id?        yang:uuid
           +--rw tp-connection-specific-attribute
           |  +--rw connection* [connection-class]
           |  |  +--rw connection-class    layer-rate
           |  |  +--rw (connection-type)?
           |  |     +--:(lr-eth)
           |  |     |  +--rw eth
           |  |     |     +--rw access-type?   eth-encap-type
           |  |     |     +--rw (accessVlanValue)?
           |  |     |     |  +--:(qinq)
           |  |     |     |  |  +--rw qinq
           |  |     |     |  |     +--rw cvlan*   uint64
           |  |     |     |  |     +--rw svlan?   uint64
           |  |     |     |  +--:(dot1q)
           |  |     |     |     +--rw dot1q
           |  |     |     |        +--rw dot1q*   uint64
           |  |     |     +--rw vlan-action?   ethernet-action
           |  |     |     +--rw action?        string
           |  |     +--:(lr-ip)
           |  |     |  +--rw ip
           |  |     |     +--rw ip-address?   inet:ip-address
           |  |     |     +--rw mtu?          uint64
           |  |     +--:(lr-pw)
           |  |        +--rw pw
           |  |           +--rw control-word?   boolean
           |  |           +--rw vlan-action?    pwtagmode
           |  +--rw security-attribute
           |  |  +--rw security
           |  |     +--rw authentication
           |  |     +--rw encryption {encryption}?
           |  |        +--rw enabled?               boolean
           |  |        +--rw layer?                 enumeration
           |  |        +--rw algorithm?             string
           |  |        +--rw (key-type)?
           |  |           +--:(psk)
           |  |              +--rw preshared-key?   string
           |  +--rw qos-attribute
           |  |  +--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)?
           |  |     |     |  +--:(match-flow)



Even, et al.            Expires September 9, 2019              [Page 13]


Internet-Draft           Composed VPN YANG Model              March 2019


           |  |     |     |  |  +--rw match-flow
           |  |     |     |  |     +--rw dscp?                inet:dscp
           |  |     |     |  |     +--rw exp?                 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 peer-remote-node*    string
           |  |     |     |  |     +--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 src-mac?             yang:mac-address
           |  |     |     |  |     +--rw dst-mac?             yang:mac-address
           |  |     |     |  |     +--rw protocol-field?      union
           |  |     |     |  +--:(match-application)
           |  |     |     |     +--rw match-application?   identityref
           |  |     |     +--rw target-class-id?           string
           |  |     +--rw qos-profile
           |  |        +--rw (qos-profile)?
           |  |           +--:(standard)
           |  |           |  +--rw profile?   string
           |  |           +--:(custom)
           |  |              +--rw classes {qos-custom}?
           |  |                 +--rw class* [class-id]
           |  |                    +--rw class-id      string
           |  |                    +--rw 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



Even, et al.            Expires September 9, 2019              [Page 14]


Internet-Draft           Composed VPN YANG Model              March 2019


           |  +--rw protection-attribute
           |     +--rw access-priority?   uint32
           +--rw routing-protocol* [type]
              +--rw type            protocol-type
              +--rw (para)?
                 +--:(static)
                 |  +--rw static* [index]
                 |     +--rw index               uint32
                 |     +--rw dest-cidr?          string
                 |     +--rw egress-tp?          yang:uuid
                 |     +--rw route-preference?   string
                 |     +--rw next-hop?           inet:ip-address
                 +--:(bgp)
                    +--rw bgp* [index]
                       +--rw index                uint32
                       +--rw autonomous-system    uint32
                       +--rw address-family*      address-family
                       +--rw max-prefix?          int32
                       +--rw peer-address?        inet:ip-address
                       +--rw crypto-algorithm     identityref
                       +--rw key-string
                          +--rw (key-string-style)?
                             +--:(keystring)
                             |  +--rw keystring?            string
                             +--:(hexadecimal) {hex-key-string}?
                                +--rw hexadecimal-string?   yang:hex-string

5.1.  VPN Hierarchy

   The composed VPN and segment VPN contain the following common
   parameters:

   o  vpn-id: Refers to an internal reference for this VPN service

   o  vpn-service-type: Combination of L3VPN service type and L2VPN
      service type per [RFC8466] and [RFC8299], including VPWS,VPLS,EVPN
      and L3VPN.

   o  vpn-topology: Combination of L3VPN topology and L2VPN topology,
      including hub-spoke, any-to-any and point-to-point.

   o  Tunnel-type:MPLS,MPLS-TP,SR,SRv6

   Suppose a composed VPN is a L3VPN which could initially has sites
   connected to a single SP domain and may later add more sites to other
   domains in the SP network.  Thus, a composed VPN could has one
   segment VPN at the beginning, and later has more segment VPNs.




Even, et al.            Expires September 9, 2019              [Page 15]


Internet-Draft           Composed VPN YANG Model              March 2019


5.2.  Access Point(AP)

   As the site containers of the L3SM and L2SM represent the connection
   characteristics that the CE connects to the provider network from the
   perspective of the customer, AP represents the connection
   characteristics that the PE connects to VPN from the perspective of
   the provider.  Therefore, there are two main aspects relates to the
   AP modelling:

   o  The AP component under composed VPN container describes the intent
      parameters mapping from the L3SM and L2SM, and the AP component
      under the segment VPN container describes the configuration
      parameters of the specific domain derived from the decomposition
      of composed VPN model.

   o  In a specific segment VPN, the AP component not only describes the
      CE-PE connection, but also defines inter-domain connection
      parameters between ASBR peer.  The connection between PE and ASBR
      is related to configuration of network elements and not part of
      segment VPN model.

5.2.1.  AP peering with CE

   The AP parameters contains the following group of parameters:

   Basic AP parameters:  topology role could be hub role, leaf role

   Connection:   has a knob to accommodate either Layer2 or Layer 3 data
      plane connection

   Control plane peering:  has a knob to accommodate either Layer 2
      protocol or Layer 3 routing protocol

   QoS profile and QoS-classification-policy:   has a knob to
      accommodate either Layer 2 QoS profile and qos-classification-
      policy or Layer 3 QoS profile and Qos-classification-policy, to
      describe both per AP bandwidth and per flow QoS.

   Security Policy:  has a knob to accommodate either Layer 2 QoS
      profile and qos-classification-policy or Layer 3 QoS profile and
      qos-classification-policy, to describe both per AP bandwidth and
      per flow QoS.

   Although both the composed VPN and segment VPN use the AP to describe
   the connection parameters of the CE and the PE, the AP parameter of
   the composed VPN may not be directly mapped to the AP parameters of
   the segment VPN.  For example, a composed VPN is a L3VPN with one of
   its AP which specifies the IP connection parameters and per flow QOS



Even, et al.            Expires September 9, 2019              [Page 16]


Internet-Draft           Composed VPN YANG Model              March 2019


   requirement.  During decomposition, depending on the capability of
   the accessed domain which the segment VPN resides, the AP of the
   segment VPN could only support Ethernet connection and per port
   bandwidth guarantee.  Therefore, the AP could only configure with L2
   connection and per AP bandwidth setting.

5.2.2.  AP peering for inter-domains connection

   The AP which describes the inter-domains connection could only exist
   in segment VPN.  There are three options in connecting segment VPN
   across inter-domain link.  With L3VPN, L2VPN or mixture, the option
   could be:

   +------------+----------------+------------+----------+
   |Interworking|  AP type       |AP CP       |AP DP     |
   | Option     |                |remote peer |          |
   +------------+----------------+------------+----------+
   |  Option A  |  ASBR LTP      | ASBR       | Interface|
   +------------+----------------+------------+----------+
   |  Option B  |  ASBR          | ASBR       | LSP label|
   +------------+----------------+------------+----------+
   |  Option C  |  PE,ASBR       | remote PE  | LSP label|
   +------------+----------------+------------+----------+

   The AP parameters contains the following group of parameters:

   Basic AP parameters:   Inter-AS interworking option could be Option
      A, Option B or Option C.

   Connection:   only specifies in Options A, Option B and C use
      dynamically allocated MPLS labels.

   Control plane peering:  BGP peering or static routing.

   QoS profile and QoS-classification-policy:  only applicable in
      Options A, Option B and C can only use MPLS EXP to differentiate
      the traffic.

   Security policy:  Options A use the similar mechanism like CE-PE
      peering, Option B could use BGP authentication to secure control
      plane communication and enable mpls label security, and Option C
      depends on the trust between the inter-domains.

5.2.2.1.  Secure inter-domain connection

   This model is applied to a single SP.  Although there are different
   domain separation, implicit trust exists between the ASs because they




Even, et al.            Expires September 9, 2019              [Page 17]


Internet-Draft           Composed VPN YANG Model              March 2019


   have the same operational control, for example from orchestrator's
   perspective.

   The model specifies different security parameters depending on the
   various Inter-AS options:

   o  Option A uses interfaces or subinterfaces between autonomous
      system border routers (ASBRs) to keep the VPNs separate, so there
      is strict separation between VPNs.

   o  Option B can be secured with configuration on the control plane
      and the data plane.  On the control plane, the session can be
      secured by use of peer authentication of BGP with message digest 5
      (MD5) and TCP Authentication Option(TCP-AO), maximum route limits
      per peer and per VPN, dampening, and so on.  In addition, prefix
      filters can be deployed to control which routes can be received
      from the other AS.  On the data plane, labeled packets are
      exchanged.  The label is derived from the MP-eBGP session;
      therefore, the ASBR announcing a VPN-IPv4 prefix controls and
      assigns the label for each prefix it announces.  On the data
      plane, the incoming label is then checked to verify that this
      label on the data plane has really been assigned on the control
      plane.  Therefore, it is impossible to introduce fake labels from
      one AS to another.  The Authentication parameter could be set
      under the BGP peering configuration.  An MPLS label security could
      be enabled under the connection node.

   o  Option C can also be secured well on the control plane, but the
      data plane does not provide any mechanism to check and block the
      packets to be sent into the other AS.  On the control plane, model
      C has two interfaces between autonomous systems: The ASBRs
      exchange IPv4 routes with labels via eBGP.  The purpose is to
      propagate the PE loopback addresses to the other AS so that LSPs
      can be established end to end.  The other interface is the RRs
      exchange VPN-IPv4 routes with labels via multihop MP-eBGP.  The
      prefixes exchanged can be controlled through route maps, equally
      the route targets.  On the data plane, the traffic exchanged
      between the ASBRs contains two labels.  One is VPN label set by
      the ingress PE to identify the VPN.  The other is PE label
      Specifies the LSP to the egress PE.  The Authentication and
      routing policy parameter could be set under the BGP peering
      configuration.

   The security options supported in the model are limited but may be
   extended via augmentation.






Even, et al.            Expires September 9, 2019              [Page 18]


Internet-Draft           Composed VPN YANG Model              March 2019


5.2.2.2.  Inter-domain QoS decomposition

   The APs connected between the domains are aggregation points, and
   traffic from different CEs of the combined VPN cross-domain will
   interact through these aggregation points.  To provide consistent QoS
   configuration, when several domains are involved in the provisioning
   of a VPN, topology, domain functionality and other factors need to be
   considered.

   Option A can achieve most granular QoS implementation since IP
   traffic passes the inter-domain connection.  Thus, Option A can set
   configuration with per sub-interface and IP DSCP.  Option B and
   Option C only provide MPLS EXP differentiation.  QoS mechanisms that
   are applied only to IP traffic cannot be carried.

   In some cases, there is need to re-mark packets at Layer 3 to
   indicate whether traffic is in agreement.  Because MPLS labels
   include 3 bits that commonly are used for QoS marking, it is possible
   for "tunnel DiffServ" to preserve Layer 3 DiffServ markings through a
   service provider's MPLS VPN cloud while still performing re-marking
   (via MPLS EXP bits) within the cloud to indicate in- or out-of-
   agreement traffic.

6.  Composed VPN YANG Module

<CODE BEGINS> file "ietf-composed-vpn-svc.yang"
module ietf-composed-vpn-svc {
    namespace "urn:ietf:params:xml:ns:yang:ietf-composed-vpn-svc" ;
    prefix composed-vpn ;
    import ietf-yang-types {
        prefix yang;
    }
    import ietf-segment-vpn {
        prefix segment-vpn;
    }
    organization "IETF OPSAWG Working Group";
    contact "
     WG Web:   <https://datatracker.ietf.org/wg/opsawg>
        WG List:  <mailto:netmod@ietf.org>

        Editor:   Roni Even
                  <mailto:roni.even@huawei.com>
                  Bo Wu
                  <mailto:lana.wubo@huawei.com>
                  Qin Wu
                  <mailto:bill.wu@huawei.com>
                  Ying Cheng
                  <mailto:chengying10@chinaunicom.cn>";



Even, et al.            Expires September 9, 2019              [Page 19]


Internet-Draft           Composed VPN YANG Model              March 2019


    description "ietf-compsed-vpn";
    revision 2018-08-21 {
        reference "draft-evenwu-opsawg-yang-composed-vpn-00";
    }

    grouping vpn-basic {
        description "VPNBasicInfo Grouping.";
        leaf topo {
            type segment-vpn:vpn-topology;
            description "current support for full-mesh and
            point_to_multipoint(hub-spoke), others is reserved for
            future extensions." ;
        }
        leaf service-type {
            type segment-vpn:service-type;
            description "current support for mpls l3vpn/vxlan/L2VPN/hybrid
            VPN overlay, others is reserved for future extensions." ;
        }
        leaf tunnel-type {
            type segment-vpn:tunnel-type;
            description "mpls|vxlan overlay l3vpn|eth over sdh|nop";
        }
        leaf admin-state {
            type segment-vpn:admin-state;
            description "administrative status." ;
         }
       leaf oper-State {
            type segment-vpn:oper-state;
            config false;
            description "Operational status." ;
        }
        leaf sync-state {
            type segment-vpn:sync-state;
            config false;
            description "Sync status." ;
        }
        leaf start-time {
            type yang:date-and-time;
            description "Service lifecycle: request for service start
            time." ;
        }
    }

    container composed-vpns{
        description "";
        list composed-vpn {
            key "vpn-id";
            description "List for composed VPNs.";



Even, et al.            Expires September 9, 2019              [Page 20]


Internet-Draft           Composed VPN YANG Model              March 2019


            uses composedvpn;
        }
    }

    grouping composedvpn {
        description "ComposedVPN Grouping.";
        leaf vpn-id {
            type yang:uuid;
            description "Composed VPN identifier." ;
        }
        leaf vpn-name {
            type string  {length "0..200";}
            description "Composed VPN Name. Local administration meaning" ;
        }
        leaf customer-name {
            type yang:uuid;
            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." ;
        }
        uses vpn-basic;
        list segment-vpn {
            key "vpn-id";
            description "SegVpn list ";
            uses segment-vpn:VPN;
        }
        list access-point {
            key "tp-id";
            description "TP list of the access links which associated
            with CE and PE";
            uses segment-vpn:pe-termination-point;
        }
    }
}
<CODE ENDS>

7.  Segment VPN YANG Module

<CODE BEGINS> file "ietf-segment-vpn.yang"
module ietf-segment-vpn {
  namespace "urn:ietf:params:xml:ns:yang:ietf-segment-vpn";
  prefix segment-vpn;




Even, et al.            Expires September 9, 2019              [Page 21]


Internet-Draft           Composed VPN YANG Model              March 2019


  import ietf-yang-types {
    prefix yang;
  }
  import ietf-inet-types {
    prefix inet;
  }
  import ietf-key-chain {
    prefix keychain;
  }
  import ietf-netconf-acm {
    prefix nacm;
  }

  organization
    "IETF OPSAWG Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/opsawg>
     WG List:  <mailto:netmod@ietf.org>

     Editor:
       Roni Even
          <mailto:roni.even@huawei.com>
          Bo Wu
          <mailto:lana.wubo@huawei.com>
          Qin Wu
          <mailto:bill.wu@huawei.com>
          Cheng Ying
          <mailto:chengying10@chinaunicom.cn>";
  description
    "This YANG module defines a generic service configuration
     model for segment VPNs.";

  revision 2019-01-30 {
    reference
      "draft-opsawg-evenwu-yang-composed-vpn-02";
  }

  feature encryption {
    description
      "Enables support of encryption.";
  }

  feature qos {
    description
      "Enables support of classes of services.";
  }

  feature qos-custom {



Even, et al.            Expires September 9, 2019              [Page 22]


Internet-Draft           Composed VPN YANG Model              March 2019


    description
      "Enables support of the custom QoS profile.";
  }

  feature hex-key-string {
    description
      "Support hexadecimal key string.";
  }

  identity protocol-type {
    description
      "Base identity for protocol field type.";
  }

  identity tcp {
    base protocol-type;
    description
      "TCP protocol type.";
  }

  identity udp {
    base protocol-type;
    description
      "UDP protocol type.";
  }

  identity icmp {
    base protocol-type;
    description
      "ICMP 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.";



Even, et al.            Expires September 9, 2019              [Page 23]


Internet-Draft           Composed VPN YANG Model              March 2019


  }

  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 customer-application {
    description
      "Base identity for customer application.";
  }

  identity web {
    base customer-application;
    description
      "Identity for Web application (e.g., HTTP, HTTPS).";
  }

  identity mail {
    base customer-application;
    description
      "Identity for mail application.";
  }

  identity file-transfer {
    base customer-application;
    description
      "Identity for file transfer application (e.g., FTP, SFTP).";
  }



Even, et al.            Expires September 9, 2019              [Page 24]


Internet-Draft           Composed VPN YANG Model              March 2019


  identity database {
    base customer-application;
    description
      "Identity for database application.";
  }

  identity social {
    base customer-application;
    description
      "Identity for social-network application.";
  }

  identity games {
    base customer-application;
    description
      "Identity for gaming application.";
  }

  identity p2p {
    base customer-application;
    description
      "Identity for peer-to-peer application.";
  }

  identity network-management {
    base customer-application;
    description
      "Identity for management application
       (e.g., Telnet, syslog, SNMP).";
  }

  identity voice {
    base customer-application;
    description
      "Identity for voice application.";
  }

  identity video {
    base customer-application;
    description
      "Identity for video conference application.";
  }

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




Even, et al.            Expires September 9, 2019              [Page 25]


Internet-Draft           Composed VPN YANG Model              March 2019


  identity outbound {
    base qos-profile-direction;
    description
      "Identity for outbound direction.";
  }

  identity inbound {
    base qos-profile-direction;
    description
      "Identity for inbound direction.";
  }

  identity both {
    base qos-profile-direction;
    description
      "Identity for both inbound direction
       and outbound direction.";
  }

  typedef access-point-type {
    type enumeration {
      enum ce-peering {
        description
          "indicates access type with connection to CE";
      }
      enum remote-as-peering {
        description
          "indicates access type with connection to ASBR with opion A,B,C ";
      }
    }
    description
      "The access-point-type could be peering with CE or ASBR
       depending on which network that a PE interconnects with.";
  }

  typedef bgp-password-type {
    type string;
    description
      "Authentication Type (None, Simple Password, Keyed MD5,
       Meticulous Keyed MD5, Keyed SHA1, Meticulous Keyed SHA1";
  }

  typedef topology-role {
    type enumeration {
      enum hub {
        description
          "hub";
      }



Even, et al.            Expires September 9, 2019              [Page 26]


Internet-Draft           Composed VPN YANG Model              March 2019


      enum spoke {
        description
          "spoke";
      }
      enum other {
        description
          "other";
      }
    }
    description
      "Topo Node Role.";
  }

  typedef qos-config-type {
    type enumeration {
      enum template {
        description
          "standard.";
      }
      enum customer {
        description
          "custom.";
      }
    }
    description
      "Qos Config Type.";
  }

  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.";
  }

  typedef tp-type {
    type enumeration {
      enum phys-tp {
        description
          "Physical termination point";



Even, et al.            Expires September 9, 2019              [Page 27]


Internet-Draft           Composed VPN YANG Model              March 2019


      }
      enum ctp {
        description
          "CTP";
      }
      enum trunk {
        description
          "TRUNK";
      }
      enum loopback {
        description
          "LoopBack";
      }
      enum tppool {
        description
          "TPPool";
      }
    }
    description
      "Tp Type.";
  }

  typedef layer-rate {
    type enumeration {
      enum lr-unknow {
        description
          "Layer Rate UNKNOW.";
      }
      enum lr-ip {
        description
          "Layer Rate IP.";
      }
      enum lr-eth {
        description
          "Layer Rate Ethernet.";
      }
      enum lr_vxlan {
        description
          "Layer Rate VXLAN.";
      }
    }
    description
      "Layer Rate.";
  }

  typedef admin-state {
    type enumeration {
      enum active {



Even, et al.            Expires September 9, 2019              [Page 28]


Internet-Draft           Composed VPN YANG Model              March 2019


        description
          "Active status";
      }
      enum inactive {
        description
          "Inactive status";
      }
      enum partial {
        description
          "Partial status";
      }
    }
    description
      "Admin State.";
  }

  typedef oper-state {
    type enumeration {
      enum up {
        description
          "Up status";
      }
      enum down {
        description
          "Down status";
      }
      enum degrade {
        description
          "Degrade status";
      }
    }
    description
      "Operational Status.";
  }

  typedef sync-state {
    type enumeration {
      enum sync {
        description
          "Sync status";
      }
      enum out-sync {
        description
          "Out sync status";
      }
    }
    description
      "Sync Status";



Even, et al.            Expires September 9, 2019              [Page 29]


Internet-Draft           Composed VPN YANG Model              March 2019


  }

  typedef eth-encap-type {
    type enumeration {
      enum default {
        description
          "DEFAULT";
      }
      enum dot1q {
        description
          "DOT1Q";
      }
      enum qinq {
        description
          "QINQ";
      }
      enum untag {
        description
          "UNTAG";
      }
    }
    description
      "Ethernet Encap Type.";
  }

  typedef protocol-type {
    type enumeration {
      enum static {
        description
          "Static Routing";
      }
      enum bgp {
        description
          "bgp";
      }
      enum rip {
        description
          "rip";
      }
      enum ospf {
        description
          "ospf";
      }
      enum isis {
        description
          "isis";
      }
    }



Even, et al.            Expires September 9, 2019              [Page 30]


Internet-Draft           Composed VPN YANG Model              March 2019


    description
      "Routing Protocol Type";
  }

  typedef tunnel-type {
    type enumeration {
      enum MPLS {
        description
          "MPLS";
      }
      enum MPLS-TP {
        description
          "MPLS-TP";
      }
      enum MPLS-SR {
        description
          "MPLS Segment Routing";
      }
      enum SRv6 {
        description
          "SRv6";
      }
    }
    description
      "VPN Tunnel Type.";
  }

  typedef service-type {
    type enumeration {
      enum l3vpn {
        description
          "l3vpn";
      }
      enum l2vpn {
        description
          "l2vpn";
      }
    }
    description
      "VPN Service Type.";
  }

  typedef vpn-topology {
    type enumeration {
      enum point-to-point {
        description
          "point to point";
      }



Even, et al.            Expires September 9, 2019              [Page 31]


Internet-Draft           Composed VPN YANG Model              March 2019


      enum any-to-any {
        description
          "any to any";
      }
      enum hub-spoke {
        description
          "hub and spoke VPN topology.";
      }
      enum hub-spoke-disjoint {
        description
          "Hub and spoke VPN topology where
           Hubs cannot communicate with each other ";
      }
    }
    description
      "Topology.";
  }

  typedef ethernet-action {
    type enumeration {
      enum nop {
        description
          "nop";
      }
      enum untag {
        description
          "UNTAG";
      }
      enum stacking {
        description
          "STACKING";
      }
    }
    description
      "Ethernet Action.";
  }

  typedef color-type {
    type enumeration {
      enum green {
        description
          "green";
      }
      enum yellow {
        description
          "yellow";
      }
      enum red {



Even, et al.            Expires September 9, 2019              [Page 32]


Internet-Draft           Composed VPN YANG Model              March 2019


        description
          "red";
      }
      enum all {
        description
          "all";
      }
    }
    description
      "Color Type.";
  }

  typedef action-type {
    type enumeration {
      enum nop {
        description
          "nop";
      }
      enum bandwidth {
        description
          "bandwidth";
      }
      enum pass {
        description
          "pass";
      }
      enum discard {
        description
          "discard";
      }
      enum remark {
        description
          "remark";
      }
      enum redirect {
        description
          "redirect";
      }
      enum recolor {
        description
          "recolor";
      }
      enum addRt {
        description
          "addRt";
      }
    }
    description



Even, et al.            Expires September 9, 2019              [Page 33]


Internet-Draft           Composed VPN YANG Model              March 2019


      "Action Type";
  }

  typedef pwtagmode {
    type enumeration {
      enum raw {
        description
          "RAW";
      }
      enum tagged {
        description
          "TAGGED";
      }
    }
    description
      "PWTagMode";
  }

  grouping QinQVlan {
    description
      "QinQVlan Grouping.";
    leaf-list cvlan {
      type uint64;
      description
        "cvlan List.";
    }
    leaf svlan {
      type uint64;
      description
        "svlan.";
    }
  }

  grouping Dot1QVlan {
    description
      "Dot1QVlan Grouping.";
    leaf-list dot1q {
      type uint64;
      description
        "dot1q Vlan List";
    }
  }

  grouping tp-connection-type {
    description
      "Tp Type Spec Grouping.";
    choice connection-type {
      description



Even, et al.            Expires September 9, 2019              [Page 34]


Internet-Draft           Composed VPN YANG Model              March 2019


        "Spec Value";
      case lr-eth {
        container eth {
          description
            "ethernetSpec";
          uses ethernet-spec;
        }
      }
      case lr-ip {
        container ip {
          description
            "ipSpec";
          uses ipspec;
        }
      }
      case lr-pw {
        container pw {
          description
            "PwSpec";
          uses pwspec;
        }
      }
    }
  }

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

  grouping 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.";
        }



Even, et al.            Expires September 9, 2019              [Page 35]


Internet-Draft           Composed VPN YANG Model              March 2019


        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.";
      }
      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 customer.";
          }
        }
        description
          "Type of keys to be used.";
      }
      description
        "Encryption parameters.";
    }
    description
      "This grouping defines encryption parameters for a site.";
  }

  grouping security-attribute {
    container security {
      uses security-authentication;
      uses security-encryption;
      description
        "Site-specific security parameters.";
    }
    description
      "Grouping for security parameters.";



Even, et al.            Expires September 9, 2019              [Page 36]


Internet-Draft           Composed VPN YANG Model              March 2019


  }

  grouping flow-definition {
    container match-flow {
      leaf dscp {
        type inet:dscp;
        description
          "DSCP value.";
      }
      leaf exp {
        type inet:dscp;
        description
          "EXP value.";
      }
      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.";



Even, et al.            Expires September 9, 2019              [Page 37]


Internet-Draft           Composed VPN YANG Model              March 2019


        }
        description
          "Match on Layer 4 src port.";
      }
      leaf-list peer-remote-node {
        type string;
        description
          "Identify a peer remote node as traffic destination.";
      }
      container l4-src-port-range {
        leaf lower-port {
          type inet:port-number;
          description
            "Lower boundary for port.";
        }
        leaf upper-port {
          type inet:port-number;
          must '. >= ../lower-port' {
            description
              "Upper boundary 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;



Even, et al.            Expires September 9, 2019              [Page 38]


Internet-Draft           Composed VPN YANG Model              March 2019


          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
            "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 src-mac {
        type yang:mac-address;
        description
          "Source MAC.";
      }
      leaf dst-mac {
        type yang:mac-address;
        description
          "Destination MAC.";
      }
      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.";
  }



Even, et al.            Expires September 9, 2019              [Page 39]


Internet-Draft           Composed VPN YANG Model              March 2019


  grouping 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.";
        }
        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 {



Even, et al.            Expires September 9, 2019              [Page 40]


Internet-Draft           Composed VPN YANG Model              March 2019


            description
              "Standard QoS profile.";
            leaf profile {
              type string;
              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";
                  }
                  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



Even, et al.            Expires September 9, 2019              [Page 41]


Internet-Draft           Composed VPN YANG Model              March 2019


                          "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";
                        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 {



Even, et al.            Expires September 9, 2019              [Page 42]


Internet-Draft           Composed VPN YANG Model              March 2019


                    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 segment network.";
  }

  grouping remote-peer-tp {
    description
      "remote-peer-tp Grouping.";
    leaf remote-id {
      type yang:uuid;
      description
        "Router ID of the remote peer";
    }
    leaf location {
      type string {
        length "0..400";



Even, et al.            Expires September 9, 2019              [Page 43]


Internet-Draft           Composed VPN YANG Model              March 2019


      }
      description
        "CE device location ";
    }
    leaf remote-tp-address {
      type inet:ip-address;
      description
        "TP IP address";
    }
    leaf remote-node-id {
      type yang:uuid;
      description
        "directly connected NE node ID, only valid in
         asbr ";
    }
    leaf remote-tp-id {
      type yang:uuid;
      description
        "Directly connected TP id, only valid in asbr";
    }
  }

  grouping tp-connection-specific-attribute {
    description
      "tp connectin specific attributes";
    list connection {
      key "connection-class";
      leaf connection-class {
        type layer-rate;
        description
          "connection class and has one to one
         relation with the corresponding layer.";
      }
      uses tp-connection-type;
      description
        "typeSpecList";
    }
    container security-attribute {
      description
        "tp security Parameters.";
      uses security-attribute;
    }
    container qos-attribute {
      description
        "tp Qos Parameters.";
      uses segment-service-basic;
      uses service-qos-profile;
    }



Even, et al.            Expires September 9, 2019              [Page 44]


Internet-Draft           Composed VPN YANG Model              March 2019


    container protection-attribute {
      description
        "tp protection parameters.";
      leaf access-priority {
        type uint32;
        default "100";
        description
          "Defines the priority for the access.
           The higher the access-priority value,
           the higher the preference of the
           access will be.";
      }
    }
  }

  grouping tp-common-attribute {
    description
      "tp-common-attribute Grouping.";
    leaf tp-id {
      type yang:uuid;
      description
        "An identifier for termination point on a node.";
    }
    leaf tp-name {
      type string {
        length "0..200";
      }
      description
        "The termination point Name on a node. It conforms to
         name rule defined in system. Example FE0/0/1, GE1/2/1.1,
         Eth-Trunk1.1, etc";
    }
    leaf node-id {
      type yang:uuid;
      description
        "Identifier for a node.";
    }
    leaf access-point-type {
      type access-point-type;
      description
        "access-point-type, for example:peering with CE ";
    }
    leaf inter-as-option {
      type enumeration {
        enum optiona {
          description
            "Inter-AS Option A";
        }



Even, et al.            Expires September 9, 2019              [Page 45]


Internet-Draft           Composed VPN YANG Model              March 2019


        enum optionb {
          description
            "Inter-AS Option B";
        }
        enum optionc {
          description
            "Inter-AS Option C";
        }
      }
      description
        "Foo";
    }
    leaf topology-role {
      type topology-role;
      description
        "hub/spoke role, etc";
    }
  }

  grouping routing-protcol {
    description
      "Routing Protocol Grouping.";
    leaf type {
      type protocol-type;
      description
        "Protocol type";
    }
    choice para {
      description
        "para";
      case static {
        list static {
          key "index";
          uses static-config;
          description
            "staticRouteItems";
        }
      }
      case bgp {
        list bgp {
          key "index";
          uses bgp-config;
          description
            "bgpProtocols";
        }
      }
    }
  }



Even, et al.            Expires September 9, 2019              [Page 46]


Internet-Draft           Composed VPN YANG Model              March 2019


  grouping bgp-config {
    description
      "BGP Protocol Grouping.";
    leaf index {
      type uint32;
      description
        "index of BGP protocol item";
    }
    leaf autonomous-system {
      type uint32;
      mandatory true;
      description
        "Peer AS number in case the peer
         requests BGP routing.";
    }
    leaf-list address-family {
      type address-family;
      min-elements 1;
      description
        "If BGP is used on this site, this node
         contains configured value. This node
         contains at least one address family
         to be activated.";
    }
    leaf max-prefix {
      type int32;
      description
        "maximum number limit of prefixes.";
    }
    leaf peer-address {
      type inet:ip-address;
      description
        "peerIp";
    }
    leaf crypto-algorithm {
      type identityref {
        base keychain:crypto-algorithm;
      }
      mandatory true;
      description
        "Cryptographic algorithm associated with key.";
    }
    container key-string {
      description
        "The key string.";
      nacm:default-deny-all;
      choice key-string-style {
        description



Even, et al.            Expires September 9, 2019              [Page 47]


Internet-Draft           Composed VPN YANG Model              March 2019


          "Key string styles";
        case keystring {
          leaf keystring {
            type string;
            description
              "Key string in ASCII format.";
          }
        }
        case hexadecimal {
          if-feature "hex-key-string";
          leaf hexadecimal-string {
            type yang:hex-string;
            description
              "Key in hexadecimal string format.  When compared
               to ASCII, specification in hexadecimal affords
               greater key entropy with the same number of
               internal key-string octets.  Additionally, it
               discourages usage of well-known words or
               numbers.";
          }
        }
      }
    }
  }

  grouping static-config {
    description
      "StaticRouteItem Grouping.";
    leaf index {
      type uint32;
      description
        "static item index";
    }
    leaf dest-cidr {
      type string;
      description
        "address prefix specifying the set of
         destination addresses for which the route may be
         used. ";
    }
    leaf egress-tp {
      type yang:uuid;
      description
        "egress tp";
    }
    leaf route-preference {
      type string;
      description



Even, et al.            Expires September 9, 2019              [Page 48]


Internet-Draft           Composed VPN YANG Model              March 2019


        "route priority. Ordinary, work route have
         higher priority.";
    }
    leaf next-hop {
      type inet:ip-address;
      description
        "Determines the outgoing interface and/or
         next-hop address(es), or a special operation to be
         performed on a packet..";
    }
  }

  grouping ethernet-spec {
    description
      "Ethernet Spec Grouping.";
    leaf access-type {
      type eth-encap-type;
      description
        "access frame type";
    }
    choice accessVlanValue {
      description
        "accessVlanValue";
      case qinq {
        container qinq {
          description
            "qinqVlan";
          uses QinQVlan;
        }
      }
      case dot1q {
        container dot1q {
          description
            "dot1q";
          uses Dot1QVlan;
        }
      }
    }
    leaf vlan-action {
      type ethernet-action;
      description
        "specify the action when the vlan is matched";
    }
    leaf action {
      type string {
        length "0..100";
      }
      description



Even, et al.            Expires September 9, 2019              [Page 49]


Internet-Draft           Composed VPN YANG Model              March 2019


        "specify the action value.";
    }
  }

  grouping pwspec {
    description
      "PwSpec Grouping.";
    leaf control-word {
      type boolean;
      default "false";
      description
        "control Word.";
    }
    leaf vlan-action {
      type pwtagmode;
      description
        "pw Vlan Action.";
    }
  }

  grouping ipspec {
    description
      "IpSpec Grouping.";
    leaf ip-address {
      type inet:ip-address;
      description
        "master IP address";
    }
    leaf mtu {
      type uint64;
      description
        "mtu for ip layer,scope:46~9600";
    }
  }

  grouping VPN {
    description
      "VPN Grouping.";
    leaf vpn-id {
      type yang:uuid;
      description
        "VPN Identifier.";
    }
    leaf vpn-name {
      type string {
        length "0..200";
      }
      description



Even, et al.            Expires September 9, 2019              [Page 50]


Internet-Draft           Composed VPN YANG Model              March 2019


        "Human-readable name for the VPN service.";
    }
    leaf service-type {
      type service-type;
      description
        "The service type combines service types from
         RFC8299 (L3SM) and RFC8466 (L2SM),for example L3VPN,VPWS etc.
         It could be augmentated for future extensions.";
    }
    leaf topo {
      type vpn-topology;
      description
        "The VPN topology could be full-mesh,point-to-point
         and hub-spoke, others is reserved for future extensions.";
    }
    leaf tunnel-type {
      type tunnel-type;
      description
        "Tunnel Type:LDP&#65306;LDP Tunnel,RSVP-TE&#65306;RSVP-TE Tunnel
         SR-TE&#65306;SR-TE Tunnel,MPLS-TP&#65306;MPLS-TP Tunnel,VXLAN&#65306;VXLAN Tunnel
        ";
    }
    leaf admin-state {
      type admin-state;
      description
        "administrative status.";
    }
    leaf oper-state {
      type oper-state;
      config false;
      description
        "Operational status.";
    }
    leaf sync-state {
      type sync-state;
      config false;
      description
        "Sync status.";
    }
    list access-point {
      key "tp-id";
      description
        "TP list of the access links which associated
         with PE and CE or ASBR";
      uses pe-termination-point;
    }
  }




Even, et al.            Expires September 9, 2019              [Page 51]


Internet-Draft           Composed VPN YANG Model              March 2019


  grouping pe-termination-point {
    description
      "grouping for termination points.";
    uses tp-common-attribute;
    container peer-remote-node {
      description
        "TP Peering Information, including CE
         peering and ASBR peering.";
    uses remote-peer-tp;
    }
    container tp-connection-specific-attribute {
      description
        "Termination point basic info.";
      uses tp-connection-specific-attribute;
    }
    list routing-protocol {
      key "type";
      description
        "route protocol spec.";
      uses routing-protcol;
    }
  }

  grouping segment-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;
      units "bytes";
      mandatory true;
      description
        "MTU at service level.  If the service is IP,



Even, et al.            Expires September 9, 2019              [Page 52]


Internet-Draft           Composed VPN YANG Model              March 2019


         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.";
  }

  container segment-vpns {
    list segment-vpn {
      key "index";
      description
        "Segment Vpn list.";
      leaf index {
        type uint32;
        description
          "index of segment VPN in a composed VPN.";
      }
      uses VPN;
    }
    description
      "Container for Segment VPN.";
  }
}
<CODE ENDS>

8.  Service Model Usage Example

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

+-----------------------------------------------------------------------+
|                                          ------- PE2----- Spoke_Site1 |
|                                          |                            |
| Hub_Site1-----PE1------ASBR1-------- ASBR2                           |
|                                          |                            |
|                                          --------PE3 ---- Spoke_Site2 |
+----------------|----------|--------------|--------|-------------------+
                 |          |              |        |
                 |<SegVPN1>
 | Inter-AS link|<SegVPN2>
                 |          |              |        |
                 |          |              |        |
                 | Intra-AS |   Inter-AS   |Intra-AS|
                 |                                  |
                 |<--------Composed VPN ----------->|

                 Composed VPN Service Model Usage Example



Even, et al.            Expires September 9, 2019              [Page 53]


Internet-Draft           Composed VPN YANG Model              March 2019


   In this example, we want to achieve the provisioning of an end to end
   VPN service for three sites using a Hub-and-Spoke VPN service
   topology.  The end to end VPN service is stitched by two segmented
   VPN.

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

      <?xml version="1.0"?>
      <composed-vpns xmlns="urn:ietf:params:xml:ns:yang:ietf-composed-vpn-svc">
           <composed-vpn>
            <vpn-id>12456487</vpn-id>
            <topo>hub-spoke</topo>
            <service-type>hybrid</service-type>
            <segment-vpn>
              <index>1</index>
                <vpn-id>111<vpn-id>
                <topo>hub-spoke</topo>
                <service-type>l2vpn</service-type>
                <access-point>
                   <tp-id>ap1-tp1</tp-id>
                   <node-id>PE1</node-id>
                   <topology-role>hub</topology-role>
                   <peer-remote-node>
                     <remote-node-id>Hub_Site1</remote-node-id>
                   </peer-remote-node>
                    <tp-connection-specific-attribute>
                     <qos-attribute>
                     <svc-mtu>1514</svc-mtu>
                     <svc-input-bandwidth>10000000</svc-input-bandwidth>
                     <svc-output-bandwidth>10000000</svc-output-bandwidth>
                      </qos-attribute>
                   </tp-connection-specific-attribute>
                   <routing-protocol>
                     <type>bgp</type>
                     <bgp>
                     <as-no>AS1</as-no>
                     </bgp>
                  </routing-protocol>
                  </access-point>
                  <access-point>
                   <tp-id>ap1-tp2</tp-id>
                   <node-id>ASBR1</node-id>
                   <topo-role>hub</topo-role>
                   <peer-remote-node>
                     <remote-node-id>ASBR2</remote-node-id>
                   </peer-remote-node>
                   <inter-AS-option>Option A</inter-AS-option>



Even, et al.            Expires September 9, 2019              [Page 54]


Internet-Draft           Composed VPN YANG Model              March 2019


                    <tp-connection-specific-attribute>
                     <qos-attribute>
                     <svc-mtu>1514</svc-mtu>
                     <svc-input-bandwidth>10000000</svc-input-bandwidth>
                     <svc-output-bandwidth>10000000</svc-output-bandwidth>
                      </qos-attribute>
                   </tp-connection-specific-attribute>
                   <routing-protocol>
                     <type>bgp</type>
                     <bgp>
                     <as-no>AS1</as-no>
                     </bgp>
                  </routing-protocol>
                </access-point>
            </segment-vpn>
            <segment-vpn>
              <index>2</index>
                <vpn-id>222<vpn-id>
                <topo>hub-spoke</topo>
                <service-type>l3vpn</service-type>
                <access-point>
                    <tp-id>ap2-tp2</tp-id>
                    <node-id>PE2</node-id>
                    <topo-role>spoke</topo-role>
                   <peer-remote-node>
                     <remote-node-id>Spoke_Site1</remote-node-id>
                   </peer-remote-node>
                     <qos-attribute>
                     <svc-mtu>1514</svc-mtu>
                     <svc-input-bandwidth>10000000</svc-input-bandwidth>
                     <svc-output-bandwidth>10000000</svc-output-bandwidth>
                      </qos-attribute>
                     <routing-protocol>
                      <type>bgp</type>
                       <bgp>
                       <as-no>ASXXX</as-no>
                       </bgp>
                     </routing-protocol>
                   </access-point>
                   <access-point>
                   <tp-id>ap2-tp1</tp-id>
                   <node-id>PE3</node-id>
                    <topo-role>spoke</topo-role>
                    <peer-remote-node>
                     <remote-node-id>Spoke_Site2</remote-node-id>
                   </peer-remote-node>
                     <qos-attribute>
                     <svc-mtu>1514</svc-mtu>



Even, et al.            Expires September 9, 2019              [Page 55]


Internet-Draft           Composed VPN YANG Model              March 2019


                     <svc-input-bandwidth>10000000</svc-input-bandwidth>
                     <svc-output-bandwidth>10000000</svc-output-bandwidth>
                      </qos-attribute>
                   <routing-protocol>
                     <type>bgp</type>
                     <bgp>
                     <as-no>ASXXX</as-no>
                     </bgp>
                  <routing-protocol>
                   </access-point>
                   <access-point>
                   <tp-id>ap2-tp3</tp-id>
                   <node-id>ASBR2</node-id>
                    <topo-role>hub</topo-role>
                   <peer-remote-node>
                     <remote-node-id>ASBR1</remote-node-id>
                   </peer-remote-node>
                    <qos-attribute>
                     <svc-mtu>1514</svc-mtu>
                     <svc-input-bandwidth>10000000</svc-input-bandwidth>
                     <svc-output-bandwidth>10000000</svc-output-bandwidth>
                      </qos-attribute>
                   <routing-protocol>
                     <type>bgp</type>
                     <bgp>
                     <as-no>interAS-1</as-no>
                     </bgp>
                  <routing-protocol>
                </access-point>
            </segment-vpn>
          </composed-vpn>
      </composed-vpns>

9.  Interaction with other YANG models

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

   The management system's role will be to configure the network
   elements.  The management system may be modular and distinguish the
   component instantiating the service model (let's call it "service
   component") from the component responsible for network element
   configuration (let's call it "configuration component").  The service
   is built from a combination of network elements and protocols
   configuration which also include various aspects of the underlying
   network infrastructure, including functions/devices and their
   subsystems, and relevant protocols operating at the link and network



Even, et al.            Expires September 9, 2019              [Page 56]


Internet-Draft           Composed VPN YANG Model              March 2019


   layers across multiple device.  Therefore 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 service component will take input from customer service model
   such as L3SM service model [RFC8299] or composed VPN service model
   and translate it into segment VPN in each domain and then further
   break down the segment VPN into detailed configuration view that will
   be provided by specific configuration models for network elements.

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  /composed-vpns/composed-vpn

      The entries in the list above include the whole composed vpn
      service configurations which the customer subscribes, and
      indirectly create or modify the PE,CE and ASBR device
      configurations.  Unexpected changes to these entries could lead to
      service disruption and/or network misbehavior.

   o  /composed-vpns/composed-vpn/segment-vpn

      The entries in the list above include the access points
      configurations.  As above, unexpected changes to these entries
      could lead to service disruption and/or network misbehavior.




Even, et al.            Expires September 9, 2019              [Page 57]


Internet-Draft           Composed VPN YANG Model              March 2019


   o  /composed-vpns/composed-vpn/access-point

      The entries in the list above include the access points
      configurations.  As above, unexpected changes to these entries
      could lead to service disruption and/or network misbehavior.

11.  IANA Considerations

   This document registers a URI in the IETF XML registry [RFC3688].
   Following the format in [RFC3688], the following registrations are
   requested to be made:

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

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

   This document registers two YANG modules in the YANG Module Names
   registry [RFC6020].

 ---------------------------------------------------------------------
            Name: ietf-composite-vpn-svc
            Namespace: urn:ietf:params:xml:ns:yang:ietf-composed-vpn-svc
            Prefix: composed-svc
            Reference: RFC xxxx
            Name: ietf-segmented-vpn
            Namespace: urn:ietf:params:xml:ns:yang:ietf-segment-vpn
            Prefix: segment-vpn
            Reference: RFC xxxx
 ---------------------------------------------------------------------

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

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





Even, et al.            Expires September 9, 2019              [Page 58]


Internet-Draft           Composed VPN YANG Model              March 2019


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

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

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

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

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

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






Even, et al.            Expires September 9, 2019              [Page 59]


Internet-Draft           Composed VPN YANG Model              March 2019


12.2.  Informative References

   [RFC1136]  Hares, S. and D. Katz, "Administrative Domains and Routing
              Domains: A model for routing in the Internet", RFC 1136,
              DOI 10.17487/RFC1136, December 1989,
              <https://www.rfc-editor.org/info/rfc1136>.

   [RFC8309]  Wu, Q., Liu, W., and A. Farrel, "Service Models
              Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
              <https://www.rfc-editor.org/info/rfc8309>.

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

Appendix A.  Acknowledges

   Geng Liang,Congfeng Xie, Chen Rui, LiYa Zhang,Hui Deng contributed to
   an earlier version of [I-D.chen-opsawg-composite-vpn-dm].  We would
   like to thank the authors of that document on the operators' view for
   the PE-based VPN service configuration for material that assisted in
   thinking about this document.

Authors' Addresses

   Roni Even
   Huawei Technologies,Co.,Ltd
   Tel Aviv
   Israel

   Email: roni.even@huawei.com


   Bo Wu
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: lana.wubo@huawei.com











Even, et al.            Expires September 9, 2019              [Page 60]


Internet-Draft           Composed VPN YANG Model              March 2019


   Qin Wu
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: bill.wu@huawei.com


   YingCheng
   China Unicom
   No.21 Financial Street, XiCheng District
   Beijing  100033
   China

   Email: chengying10@chinaunicom.cn



































Even, et al.            Expires September 9, 2019              [Page 61]