Tech-invite   World Map
3GPPspecs     Glossaries     T+       IETF     RFCs     Groups     SIP     ABNFs

RFC 8299

 
 
 

YANG Data Model for L3VPN Service Delivery

Part 6 of 8, p. 104 to 125
Prev Section       Next Section

 


prevText      Top      ToC       Page 104 
6.13.  Enhanced VPN Features

6.13.1.  Carriers' Carriers

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

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

                    (...)               Provider backbone

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

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

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

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

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

6.14.  External ID References

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

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

6.15.  Defining NNIs

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

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

   o  an internal administrative boundary within a single SP (e.g.,
      backhaul versus core versus data center).

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

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

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

Top      Up      ToC       Page 107 
   The figure above describes an SP network called "My network" that has
   several NNIs.  This network uses NNIs to:

   o  increase its footprint by relying on L3VPN partners.

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

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

6.15.1.  Defining an NNI with the Option A Flavor

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

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

   From a service model's perspective, this VPN connection can be seen
   as a site.  Let's say that AS B wants to extend some VPN connections
   for VPN C on AS A.  The administrator of AS B can use this service
   model to order a site on AS A.  All connection scenarios could be

Top      Up      ToC       Page 108 
   realized using the features of the current model.  As an example, the
   figure above shows two physical connections that have logical
   connections per VPN overlaid on them.  This could be seen as a dual-
   homed subVPN scenario.  Also, the administrator of AS B will be able
   to choose the appropriate routing protocol (e.g., E-BGP) to
   dynamically exchange routes between ASes.

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

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

           CSP A                              L3VPN SP B

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

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

Top      Up      ToC       Page 109 
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
 <vpn-profiles>
  <valid-provider-identifiers>
   <qos-profile-identifier>
    <id>GOLD</id>
   </qos-profile-identifier>
   <qos-profile-identifier>
    <id>PLATINUM</id>
   </qos-profile-identifier>
  </valid-provider-identifiers>
 </vpn-profiles>
 <vpn-services>
  <vpn-service>
   <vpn-id>VPN1</vpn-id>
  </vpn-service>
 </vpn-services>
 <sites>
  <site>
   <site-id>CSP_A_attachment</site-id>
   <security>
    <encryption>
     <layer>layer3</layer>
    </encryption>
   </security>
   <locations>
    <location>
     <location-id>L1</location-id>
    </location>
   </locations>
   <locations>
    <location>
     <location-id>1</location-id>
     <city>NY</city>
     <country-code>US</country-code>
    </location>
   </locations>
   <site-vpn-flavor>site-vpn-flavor-nni</site-vpn-flavor>
   <routing-protocols>
    <routing-protocol>
     <type>bgp</type>
     <bgp>
      <autonomous-system>500</autonomous-system>
      <address-family>ipv4</address-family>
     </bgp>
    </routing-protocol>
   </routing-protocols>
   <site-network-accesses>

Top      Up      ToC       Page 110 
    <site-network-access>
     <site-network-access-id>CSP_A_VN1</site-network-access-id>
     <location-reference>L1</location-reference>
     <ip-connection>
      <ipv4>
       <address-allocation-type>provider-dhcp</address-allocation-type>
      </ipv4>
      <ipv6>
       <address-allocation-type>provider-dhcp</address-allocation-type>
      </ipv6>
     </ip-connection>
     <ip-connection>
      <ipv4>
       <address-allocation-type>static-address</address-allocation-type>
       <addresses>
        <provider-address>203.0.113.1</provider-address>
        <customer-address>203.0.113.2</customer-address>
        <prefix-length>30</prefix-length>
       </addresses>
      </ipv4>
     </ip-connection>
     <service>
      <svc-input-bandwidth>450000000</svc-input-bandwidth>
      <svc-output-bandwidth>450000000</svc-output-bandwidth>
      <svc-mtu>1514</svc-mtu>
     </service>
     <security>
      <encryption>
       <layer>layer3</layer>
      </encryption>
     </security>
     <vpn-attachment>
      <vpn-id>VPN1</vpn-id>
      <site-role>any-to-any-role</site-role>
     </vpn-attachment>
    </site-network-access>
   </site-network-accesses>
   <management>
    <type>customer-managed</type>
   </management>
  </site>
 </sites>
</l3vpn-svc>

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

Top      Up      ToC       Page 111 
6.15.2.  Defining an NNI with the Option B Flavor

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

   In option B, the two ASes are connected to each other with physical
   links on ASBRs.  For resiliency purposes, there may be multiple
   physical connections between the ASes.  The VPN "connection" between
   ASes is done by exchanging VPN routes through MP-BGP [RFC4760].

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

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

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

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

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

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

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

   Those modelings are currently out of scope for this document.

          CSP A                               L3VPN SP B

     -----------------                    ------------------
    /                 \                  /                  \
   |       |           |                |                    |
   |  VM --|       ++++++++   NNI    ++++++++                |--- VPN1
   |       |       +      +__________+      +                |   Site#1
   |       |-------+      +          +      +                |
   |       |       + ASBR +<-MP-BGP->+ ASBR +                |
   |       |       +      +__________+      +                |
   |       |       ++++++++          ++++++++                |
   |  VM --|           |                |                    |--- VPN1
   |       |Virtual    |                |                    |   Site#2
   |       |Network    |                |                    |
   |  VM --|           |                |                    |--- VPN1
   |       |           |                |                    |   Site#3
    \                 /                 |                    |
     -----------------                  |                    |
                                         \                  /
                                          ------------------
                                                   |
                                                   |
                                                  VPN1
                                                 Site#4

   The example above describes an NNI connection between CSP A and SP
   network B.  Both SPs do not trust themselves and use a different RT
   allocation policy.  So, in terms of implementation, the customer VPN
   has a different RT in each network (RT A in CSP A and RT B in SP
   network B).  In order to connect the customer virtual network in CSP

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

6.15.3.  Defining an NNI with the Option C Flavor

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

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

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

7.  Service Model Usage Example

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

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

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

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

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

Top      Up      ToC       Page 115 
      <?xml version="1.0"?>
      <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
        <vpn-profiles>
          <valid-provider-identifiers>
            <qos-profile-identifier>
              <id>GOLD</id>
            </qos-profile-identifier>
            <qos-profile-identifier>
              <id>PLATINUM</id>
            </qos-profile-identifier>
          </valid-provider-identifiers>
        </vpn-profiles>
        <vpn-services>
          <vpn-service>
            <vpn-id>12456487</vpn-id>
            <vpn-service-topology>hub-spoke</vpn-service-topology>
          </vpn-service>
        </vpn-services>
      </l3vpn-svc>

   When receiving the request for provisioning the VPN service, the
   management system will internally (or through communication with
   another OSS component) allocate VPN RTs.  In this specific case, two
   RTs will be allocated (100:1 for Hub and 100:2 for Spoke).  The
   output of corresponding XML snippet below describes the configuration
   of Spoke_Site1.

<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
 <vpn-profiles>
  <valid-provider-identifiers>
   <qos-profile-identifier>
    <id>GOLD</id>
   </qos-profile-identifier>
   <qos-profile-identifier>
    <id>PLATINUM</id>
   </qos-profile-identifier>
  </valid-provider-identifiers>
 </vpn-profiles>
 <vpn-services>
  <vpn-service>
   <vpn-id>12456487</vpn-id>
   <vpn-service-topology>hub-spoke</vpn-service-topology>
  </vpn-service>
 </vpn-services>
 <sites>
  <site>
   <site-id>Spoke_Site1</site-id>

Top      Up      ToC       Page 116 
   <devices>
    <device>
     <device-id>D1</device-id>
    </device>
   </devices>
   <locations>
    <location>
     <location-id>1</location-id>
     <city>NY</city>
     <country-code>US</country-code>
    </location>
   </locations>
   <security>
    <encryption>
     <layer>layer3</layer>
    </encryption>
   </security>
   <routing-protocols>
    <routing-protocol>
     <type>bgp</type>
     <bgp>
      <autonomous-system>500</autonomous-system>
      <address-family>ipv4</address-family>
      <address-family>ipv6</address-family>
     </bgp>
    </routing-protocol>
   </routing-protocols>
   <site-network-accesses>
    <site-network-access>
     <site-network-access-id>Spoke_Site1</site-network-access-id>
     <device-reference>D1</device-reference>
     <access-diversity>
      <groups>
       <group>
        <group-id>20</group-id>
       </group>
      </groups>
      <constraints>
       <constraint>
        <constraint-type>pe-diverse</constraint-type>
        <target>
         <group>
          <group-id>10</group-id>
         </group>
        </target>
       </constraint>
      </constraints>
     </access-diversity>

Top      Up      ToC       Page 117 
     <ip-connection>
      <ipv4>
       <address-allocation-type>static-address</address-allocation-type>
       <addresses>
        <provider-address>203.0.113.254</provider-address>
        <customer-address>203.0.113.2</customer-address>
        <prefix-length>24</prefix-length>
       </addresses>
      </ipv4>
      <ipv6>
       <address-allocation-type>static-address</address-allocation-type>
       <addresses>
        <provider-address>2001:db8::1</provider-address>
        <customer-address>2001:db8::2</customer-address>
        <prefix-length>64</prefix-length>
       </addresses>
      </ipv6>
     </ip-connection>
     <service>
      <svc-input-bandwidth>450000000</svc-input-bandwidth>
      <svc-output-bandwidth>450000000</svc-output-bandwidth>
      <svc-mtu>1514</svc-mtu>
     </service>
     <security>
      <encryption>
       <layer>layer3</layer>
      </encryption>
     </security>
     <vpn-attachment>
      <vpn-id>12456487</vpn-id>
      <site-role>spoke-role</site-role>
     </vpn-attachment>
    </site-network-access>
   </site-network-accesses>
   <management>
    <type>provider-managed</type>
   </management>
  </site>
 </sites>
</l3vpn-svc>

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

Top      Up      ToC       Page 118 
   that Spoke_Site1 requires PE diversity with the Hub and that the
   management system allocates PEs based on the least distance.  Based
   on the location information, the management system finds the
   available PEs in the area nearest the customer and picks one that
   fits the access-diversity constraint.

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

   Example of generated PE configuration:

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

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

Top      Up      ToC       Page 119 
   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      Up      ToC       Page 120 
   Example of generated CE configuration:

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

8.  Interaction with Other YANG Models

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

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

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

            Site A                              Site B

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

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

   The authors of this document anticipate definitions of YANG modules
   for the network elements listed below.  Note that this list is not
   exhaustive:

   o  VRF definition, including VPN policy expression.

   o  Physical interface.

   o  IP layer (IPv4, IPv6).

Top      Up      ToC       Page 122 
   o  QoS: classification, profiles, etc.

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

   o  Multicast VPN.

   o  Network address translation.

   Example of a corresponding XML snippet with a VPN site request at the
   service level, using this model:

<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
 <vpn-profiles>
  <valid-provider-identifiers>
   <qos-profile-identifier>
    <id>GOLD</id>
   </qos-profile-identifier>
   <qos-profile-identifier>
    <id>PLATINUM</id>
   </qos-profile-identifier>
  </valid-provider-identifiers>
 </vpn-profiles>
 <vpn-services>
  <vpn-service>
   <vpn-id>VPN1</vpn-id>
   <vpn-service-topology>hub-spoke</vpn-service-topology>
  </vpn-service>
 </vpn-services>
 <sites>
  <site>
   <site-id>Site A</site-id>
   <security>
    <encryption>
     <layer>layer3</layer>
    </encryption>
   </security>
   <locations>
    <location>
     <location-id>L1</location-id>
    </location>
   </locations>
   <site-network-accesses>
    <site-network-access>
     <site-network-access-id>1</site-network-access-id>
     <ip-connection>

Top      Up      ToC       Page 123 
      <ipv4>
       <address-allocation-type>static-address</address-allocation-type>
       <addresses>
        <provider-address>203.0.113.254</provider-address>
        <customer-address>203.0.113.2</customer-address>
        <prefix-length>24</prefix-length>
       </addresses>
      </ipv4>
      <ipv6>
       <address-allocation-type>provider-dhcp</address-allocation-type>
      </ipv6>
     </ip-connection>
     <service>
      <svc-mtu>1514</svc-mtu>
      <svc-input-bandwidth>10000000</svc-input-bandwidth>
      <svc-output-bandwidth>10000000</svc-output-bandwidth>
     </service>
     <location-reference>L1</location-reference>
     <vpn-attachment>
      <vpn-policy-id>VPNPOL1</vpn-policy-id>
     </vpn-attachment>
    </site-network-access>
   </site-network-accesses>
   <routing-protocols>
    <routing-protocol>
     <type>static</type>
     <static>
      <cascaded-lan-prefixes>
       <ipv4-lan-prefixes>
        <lan>198.51.100.0/30</lan>
        <next-hop>203.0.113.2</next-hop>
       </ipv4-lan-prefixes>
      </cascaded-lan-prefixes>
     </static>
    </routing-protocol>
   </routing-protocols>
   <management>
    <type>customer-managed</type>
   </management>
   <vpn-policies>
    <vpn-policy>
     <vpn-policy-id>VPNPOL1</vpn-policy-id>
     <entries>
      <id>1</id>
      <vpn>
       <vpn-id>VPN1</vpn-id>
       <site-role>any-to-any-role</site-role>
      </vpn>

Top      Up      ToC       Page 124 
     </entries>
    </vpn-policy>
   </vpn-policies>
  </site>
 </sites>
</l3vpn-svc>

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

<if:interfaces>
 <if:interface>
  <if:name>eth0</if:name>
  <if:type>ianaift:ethernetCsmacd</if:type>
  <if:description>
   Link to CE A.
  </if:description>
  <ip:ipv4>
   <ip:address>
    <ip:ip>203.0.113.254</ip:ip>
    <ip:prefix-length>24</ip:prefix-length>
   </ip:address>
   <ip:forwarding>true</ip:forwarding>
  </ip:ipv4>
 </if:interface>
</if:interfaces>
<rt:routing>
 <rt:routing-instance>
  <rt:name>VRF_CustA</rt:name>
  <rt:type>l3vpn-network:vrf</rt:type>
  <rt:description>VRF for Customer A</rt:description>
  <l3vpn-network:rd>100:1546542343</l3vpn-network:rd>
  <l3vpn-network:import-rt>100:1</l3vpn-network:import-rt>
  <l3vpn-network:export-rt>100:1</l3vpn-network:export-rt>
  <rt:interfaces>
   <rt:interface>
    <rt:name>eth0</rt:name>
   </rt:interface>
  </rt:interfaces>
  <rt:routing-protocols>
   <rt:routing-protocol>
    <rt:type>rt:static</rt:type>

Top      Up      ToC       Page 125 
    <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>



(page 125 continued on part 7)

Next Section