Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8049

YANG Data Model for L3VPN Service Delivery

Pages: 157
Obsoleted by:  8299
Part 5 of 6 – Pages 92 to 126
First   Prev   Next

ToP   noToC   RFC8049 - Page 92   prevText

7. Service Model Usage Example

As explained in Section 5, this service model is intended to be instantiated at a management layer and is not intended to be used directly on network elements. The management system serves as a central point of configuration of the overall service. This section provides an example of how a management system can use this model to configure an IP VPN service on network elements. In this example, we want to achieve the provisioning of a VPN service for three sites using a Hub-and-Spoke VPN service topology. One of the sites will be dual-homed, and load-sharing is expected. +-------------------------------------------------------------+ | Hub_Site ------ PE1 PE2 ------ Spoke_Site1 | | | +----------------------------------+ | | | | | +----------------------------------+ | Hub_Site ------ PE3 PE4 ------ Spoke_Site2 | +-------------------------------------------------------------+ The following XML describes the overall simplified service configuration of this VPN. <vpn-service> <vpn-id>12456487</vpn-id> <vpn-service-topology>hub-spoke</vpn-service-topology> </vpn-service>
ToP   noToC   RFC8049 - Page 93
   When receiving the request for provisioning the VPN service, the
   management system will internally (or through communication with
   another OSS component) allocate VPN RTs.  In this specific case, two
   RTs will be allocated (100:1 for Hub and 100:2 for Spoke).  The
   output below describes the configuration of Spoke_Site1.

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

   When receiving the request for provisioning Spoke_Site1, the
   management system MUST allocate network resources for this site.  It
   MUST first determine the target network elements to provision the
   access, particularly the PE router (and perhaps also an aggregation
   switch).  As described in Section 6.6, the management system SHOULD
   use the location information and SHOULD use the access-diversity
   constraint to find the appropriate PE.  In this case, we consider
   that Spoke_Site1 requires PE diversity with the Hub and that the
   management system allocates PEs based on the least distance.  Based
   on the location information, the management system finds the
   available PEs in the area nearest the customer and picks one that
   fits the access-diversity constraint.
ToP   noToC   RFC8049 - Page 95
   When the PE is chosen, the management system needs to allocate
   interface resources on the node.  One interface is selected from the
   pool of available PEs.  The management system can start provisioning
   the chosen PE node via whatever means the management system prefers
   (e.g., NETCONF, CLI).  The management system will check to see if a
   VRF that fits its needs is already present.  If not, it will
   provision the VRF: the RD will be derived from the internal
   allocation policy model, and the RTs will be derived from the VPN
   policy configuration of the site (the management system allocated
   some RTs for the VPN).  As the site is a Spoke site (site-role), the
   management system knows which RTs must be imported and exported.  As
   the site is provider-managed, some management RTs may also be added
   (100:5000).  Standard provider VPN policies MAY also be added in the
   configuration.

   Example of generated PE configuration:

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

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

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

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

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

8. Interaction with Other YANG Modules

As expressed in Section 5, this 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, so the component instantiating the service model (let's call it "service component") and the component responsible for network element configuration (let's call it "configuration component") may be different. l3vpn-svc | Model | | +---------------------+ | Service component | Service datastore +---------------------+ | | +---------------------+ +----| Config component |------+ / +---------------------+ \ Network / / \ \ Configuration / / \ \ models / / \ \ ++++++++ ++++++++ ++++++++ ++++++++ + CE A + ------- + PE A + + PE B + ----- + CE B + Config ++++++++ ++++++++ ++++++++ ++++++++ datastore Site A Site B In the previous sections, we provided some examples of the translation of service provisioning requests to router configuration lines. In the NETCONF/YANG ecosystem, we expect NETCONF/YANG to be used between the configuration component and network elements to configure the requested services on those elements. In this framework, specifications are expected to provide specific YANG modeling of service components on network elements. There will be a strong relationship between the abstracted view provided by this service model and the detailed configuration view that will be provided by specific configuration models for network elements.
ToP   noToC   RFC8049 - Page 99
   The authors of this document anticipate definitions of YANG models
   for the network elements listed below.  Note that this list is not
   exhaustive:

   o  VRF definition, including VPN policy expression.

   o  Physical interface.

   o  IP layer (IPv4, IPv6).

   o  QoS: classification, profiles, etc.

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

   o  Multicast VPN.

   o  Network address translation.

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

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

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

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

9. YANG Module

<CODE BEGINS> file "ietf-l3vpn-svc@2017-01-27.yang" module ietf-l3vpn-svc { namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc"; prefix l3vpn-svc; import ietf-inet-types { prefix inet; } import ietf-yang-types { prefix yang; } organization "IETF L3SM Working Group"; contact "WG List: <mailto:l3sm@ietf.org> Editor: L3SM WG Chairs: Adrian Farrel, Qin Wu "; description "This YANG module defines a generic service configuration model for Layer 3 VPNs. This model is common across all vendor implementations."; revision 2017-01-27 { description "Initial document."; reference "RFC 8049."; }
ToP   noToC   RFC8049 - Page 103
    /* Features */

    feature cloud-access {
     description
      "Allows the VPN to connect to a CSP.";
    }
    feature multicast {
     description
      "Enables multicast capabilities in a VPN.";
    }
    feature ipv4 {
     description
      "Enables IPv4 support in a VPN.";
    }
    feature ipv6 {
     description
      "Enables IPv6 support in a VPN.";
    }
    feature carrierscarrier {
     description
      "Enables support of CsC.";
    }
    feature extranet-vpn {
     description
      "Enables support of extranet VPNs.";
    }
    feature site-diversity {
     description
      "Enables support of site diversity constraints.";
    }
    feature encryption {
     description
      "Enables support of encryption.";
    }
    feature qos {
     description
      "Enables support of classes of services.";
    }
    feature qos-custom {
     description
      "Enables support of the custom QoS profile.";
    }
    feature rtg-bgp {
     description
      "Enables support of the BGP routing protocol.";
    }
ToP   noToC   RFC8049 - Page 104
    feature rtg-rip {
     description
      "Enables support of the RIP routing protocol.";
    }
    feature rtg-ospf {
     description
      "Enables support of the OSPF routing protocol.";
    }
    feature rtg-ospf-sham-link {
     description
      "Enables support of OSPF sham links.";
    }
    feature rtg-vrrp {
     description
      "Enables support of the VRRP routing protocol.";
    }
    feature fast-reroute {
     description
      "Enables support of Fast Reroute.";
    }
    feature bfd {
     description
      "Enables support of BFD.";
    }
    feature always-on {
     description
      "Enables support of the 'always-on' access constraint.";
    }
    feature requested-type {
     description
      "Enables support of the 'requested-type' access constraint.";
    }
    feature bearer-reference {
     description
      "Enables support of the 'bearer-reference' access constraint.";
    }

    /* Typedefs */

    typedef svc-id {
     type string;
     description
      "Defines a type of service component identifier.";
    }
ToP   noToC   RFC8049 - Page 105
    typedef template-id {
     type string;
     description
      "Defines a type of service template identifier.";
    }

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

    /* Identities */

    identity site-network-access-type {
     description
      "Base identity for site-network-access type.";
    }
    identity point-to-point {
     base site-network-access-type;
     description
      "Identity for point-to-point connection.";
    }
    identity multipoint {
     base site-network-access-type;
     description
      "Identity for multipoint connection.
      Example: Ethernet broadcast segment.";
    }
    identity placement-diversity {
     description
      "Base identity for site placement constraints.";
    }
    identity bearer-diverse {
     base placement-diversity;
     description
      "Identity for bearer diversity.
      The bearers should not use common elements.";
    }
ToP   noToC   RFC8049 - Page 106
    identity pe-diverse {
     base placement-diversity;
     description
      "Identity for PE diversity.";
    }
    identity pop-diverse {
     base placement-diversity;
     description
      "Identity for POP diversity.";
    }
    identity linecard-diverse {
     base placement-diversity;
     description
      "Identity for linecard diversity.";
    }
    identity same-pe {
     base placement-diversity;
     description
      "Identity for having sites connected on the same PE.";
    }
    identity same-bearer {
     base placement-diversity;
     description
      "Identity for having sites connected using the same bearer.";
    }
    identity customer-application {
     description
      "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).";
    }
ToP   noToC   RFC8049 - Page 107
    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 site-vpn-flavor {
     description
      "Base identity for the site VPN service flavor.";
    }
    identity site-vpn-flavor-single {
     base site-vpn-flavor;
     description
      "Base identity for the site VPN service flavor.
      Used when the site belongs to only one VPN.";
    }
ToP   noToC   RFC8049 - Page 108
    identity site-vpn-flavor-multi {
     base site-vpn-flavor;
     description
      "Base identity for the site VPN service flavor.
      Used when a logical connection of a site
      belongs to multiple VPNs.";
    }
    identity site-vpn-flavor-sub {
     base site-vpn-flavor;
     description
      "Base identity for the site VPN service flavor.
      Used when a site has multiple logical connections.
      Each connection may belong to different multiple VPNs.";
    }
    identity site-vpn-flavor-nni {
     base site-vpn-flavor;
     description
      "Base identity for the site VPN service flavor.
      Used to describe an NNI option A connection.";
    }
    identity management {
     description
      "Base identity for site management scheme.";
    }
    identity co-managed {
     base management;
     description
      "Base identity for co-managed site.";
    }
    identity customer-managed {
     base management;
     description
      "Base identity for customer-managed site.";
    }
    identity provider-managed {
     base management;
     description
      "Base identity for provider-managed site.";
    }
    identity address-allocation-type {
     description
      "Base identity for address-allocation-type for PE-CE link.";
    }
    identity provider-dhcp {
     base address-allocation-type;
     description
      "Provider network provides DHCP service to customer.";
    }
ToP   noToC   RFC8049 - Page 109
    identity provider-dhcp-relay {
     base address-allocation-type;
     description
      "Provider network provides DHCP relay service to customer.";
    }
    identity provider-dhcp-slaac {
     base address-allocation-type;
     description
      "Provider network provides DHCP service to customer,
      as well as SLAAC.";
    }
    identity static-address {
     base address-allocation-type;
     description
      "Provider-to-customer addressing is static.";
    }
    identity slaac {
     base address-allocation-type;
     description
      "Use IPv6 SLAAC.";
    }

    identity site-role {
     description
      "Base identity for site type.";
    }
    identity any-to-any-role {
     base site-role;
     description
      "Site in an any-to-any IP VPN.";
    }
    identity spoke-role {
     base site-role;
     description
      "Spoke site in a Hub-and-Spoke IP VPN.";
    }
    identity hub-role {
     base site-role;
     description
      "Hub site in a Hub-and-Spoke IP VPN.";
    }
ToP   noToC   RFC8049 - Page 110
    identity vpn-topology {
     description
      "Base identity for VPN topology.";
    }
    identity any-to-any {
     base vpn-topology;
     description
      "Identity for any-to-any VPN topology.";
    }
    identity hub-spoke {
     base vpn-topology;
     description
      "Identity for Hub-and-Spoke VPN topology.";
    }
    identity hub-spoke-disjoint {
     base vpn-topology;
     description
      "Identity for Hub-and-Spoke VPN topology
      where Hubs cannot communicate with each other.";
    }

    identity multicast-tree-type {
     description
      "Base identity for multicast tree type.";
    }
    identity ssm-tree-type {
     base multicast-tree-type;
     description
      "Identity for SSM tree type.";
    }
    identity asm-tree-type {
     base multicast-tree-type;
     description
      "Identity for ASM tree type.";
    }
    identity bidir-tree-type {
     base multicast-tree-type;
     description
      "Identity for bidirectional tree type.";
    }

    identity multicast-rp-discovery-type {
     description
      "Base identity for RP discovery type.";
    }
ToP   noToC   RFC8049 - Page 111
    identity auto-rp {
     base multicast-rp-discovery-type;
     description
      "Base identity for Auto-RP discovery type.";
    }
    identity static-rp {
     base multicast-rp-discovery-type;
     description
      "Base identity for static type.";
    }
    identity bsr-rp {
     base multicast-rp-discovery-type;
     description
      "Base identity for BSR discovery type.";
    }

    identity routing-protocol-type {
     description
      "Base identity for routing protocol type.";
    }
    identity ospf {
     base routing-protocol-type;
     description
      "Identity for OSPF protocol type.";
    }
    identity bgp {
     base routing-protocol-type;
     description
      "Identity for BGP protocol type.";
    }
    identity static {
     base routing-protocol-type;
     description
      "Identity for static routing protocol type.";
    }
    identity rip {
     base routing-protocol-type;
     description
      "Identity for RIP protocol type.";
    }
    identity vrrp {
     base routing-protocol-type;
     description
      "Identity for VRRP protocol type.
      This is to be used when LANs are directly connected
      to PE routers.";
    }
ToP   noToC   RFC8049 - Page 112
    identity direct {
     base routing-protocol-type;
     description
      "Identity for direct protocol type.";
    }

    identity protocol-type {
     description
      "Base identity for protocol field type.";
    }
    identity tcp {
     base protocol-type;
     description
      "TCP protocol type.";
    }
    identity udp {
     base protocol-type;
     description
      "UDP protocol type.";
    }
    identity icmp {
     base protocol-type;
     description
      "ICMP protocol type.";
    }
    identity icmp6 {
     base protocol-type;
     description
      "ICMPv6 protocol type.";
    }
    identity gre {
     base protocol-type;
     description
      "GRE protocol type.";
    }
    identity ipip {
     base protocol-type;
     description
      "IP-in-IP protocol type.";
    }
    identity hop-by-hop {
     base protocol-type;
     description
      "Hop-by-Hop IPv6 header type.";
    }
ToP   noToC   RFC8049 - Page 113
    identity routing {
     base protocol-type;
     description
      "Routing IPv6 header type.";
    }
    identity esp {
     base protocol-type;
     description
      "ESP header type.";
    }
    identity ah {
     base protocol-type;
     description
      "AH header type.";
    }

    /* Groupings */

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

      key cloud-identifier;

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

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

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

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

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

         container groups {
          list group {
           key id;

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

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

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

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

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

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

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

       uses site-group;

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

       uses site-group;
ToP   noToC   RFC8049 - Page 122
       container constraints {
        list constraint {
         key constraint-type;

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

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

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

    grouping operational-requirements {
       leaf requested-site-start {
         type yang:date-and-time;
         description
          "Optional leaf indicating requested date and time when the
          service at a particular site is expected to start.";
        }

        leaf requested-site-stop {
         type yang:date-and-time;
         description
          "Optional leaf indicating requested date and time when the
          service at a particular site is expected to stop.";
        }
     description
      "This grouping defines some operational parameters.";
    }
ToP   noToC   RFC8049 - Page 124
    grouping operational-requirements-ops {
        leaf actual-site-start {
         type yang:date-and-time;
         config false;
         description
          "Optional leaf indicating actual date and time when the
          service at a particular site actually started.";
        }
        leaf actual-site-stop {
         type yang:date-and-time;
         config false;
         description
          "Optional leaf indicating actual date and time when the
          service at a particular site actually stopped.";
        }
     description
      "This grouping defines some operational parameters.";
    }

    grouping flow-definition {
     container match-flow {
      leaf dscp {
       type inet:dscp;
       description
        "DSCP value.";
      }
      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.";
      }
ToP   noToC   RFC8049 - Page 125
      leaf ipv6-dst-prefix {
       type inet:ipv6-prefix;
       description
        "Match on IPv6 dst address.";
      }
      leaf l4-src-port {
       type inet:port-number;
       description
        "Match on Layer 4 src port.";
      }
      leaf-list target-sites {
       type svc-id;
       description
        "Identify a site as traffic destination.";
      }
      container l4-src-port-range {
       leaf lower-port {
        type inet:port-number;
        description
         "Lower boundary for port.";
       }
       leaf upper-port {
        type inet:port-number;
        must ". >= ../lower-port" {
         description
          "Upper boundary must be higher than lower boundary.";
        }
        description
         "Upper boundary for port.";
       }
       description
        "Match on Layer 4 src port range.";
      }
      leaf l4-dst-port {
       type inet:port-number;
       description
        "Match on Layer 4 dst port.";
      }
      container l4-dst-port-range {
       leaf lower-port {
        type inet:port-number;
        description
         "Lower boundary for port.";
       }
ToP   noToC   RFC8049 - Page 126
       leaf upper-port {
        type inet:port-number;
        must ". >= ../lower-port" {
         description
          "Upper boundary must be higher than lower boundary.";
        }
        description
         "Upper boundary for port.";
       }
       description
        "Match on Layer 4 dst port range.";
      }
      leaf protocol-field {
       type union {
        type uint8;
        type identityref {
         base protocol-type;
        }
       }
       description
        "Match on IPv4 protocol or IPv6 Next Header field.";
      }

      description
       "Describes flow-matching criteria.";
     }
     description
      "Flow definition based on criteria.";
    }
    grouping site-service-basic {
     leaf svc-input-bandwidth {
         type uint32;
         units bps;
         description
          "From the PE's perspective, the service input
          bandwidth of the connection.";
     }
     leaf svc-output-bandwidth {
        type uint32;
        units bps;
        description
         "From the PE's perspective, the service output
         bandwidth of the connection.";
     }


(next page on part 6)

Next Section